This is going to sound like I'm trolling, but: why not just use Ruby?
Like many Ruby developers, I left PHP because I saw the kind of stagnation the author describes at the beginning of this article. I saw lots of good ideas originating and flourishing in the Ruby world, and sometimes trickling back to PHP. I saw a more well-thought-out language that seemed worthy of all that attention. So I hopped.
The libraries and library management tools and frameworks available to me now are awesome. Ruby itself is getting faster all the time. Is there really any reason left to stick with PHP other than inertia? (I don't mean that dismissively; if you have a massive existing code base, that's real inertia and changing would be a tall order.)
You can substitute Python or Node or whatever for Ruby here, but my point is: why fight the uphill battle to bring good tools to a language when other languages already have them?
Unfortunately the common argument is not always true. To be honest at this point in time I would say PHP is actually the hardest to find hosting for. I'm a long time PHP developer and just recently tried Heroku out -- its like magic.
Best for generating web pages is a meaningless metric, and...
To be honest my main issue with PHP relates to the defense that "PHP is not as bad as people like to say.". I mean, really - its true. PHP5 is significantly better language than the previous versions, and people always over-exaggerate how bad it is. The problem is that PHP is not a good language.
Whenever I develop in Python/Ruby I actually enjoy the 'feel' of the language, and I'm often impressed by the power it has to do really complicated things in simple concise instructions. Most of the time when I'm working with PHP the feeling is very different. I can perform the same operations but generally theres far more cruft, and a couple manual lookups to see why functions behave differently when hashes ("arrays") have numeric indices (I'm looking at you array_merge!)
> PHP is actually the hardest to find hosting for.
What? No. Do you have any proof of this? I have yet to come across a "normal" shared/dedicated hosting service that doesn't support PHP. That is an insane statement.
The reason for that is because your definition of normal hosting is shared. (On a dedicated host you can run both PHP and Ruby; and they're roughly the same in terms of getting set up.)
In terms of actually finding website hosting for an application?
Saying PHP is the hardest was likely an over-exagguration, but the market for Heroku PaaS style hosting is growing massively and its Ruby runs on it very easily.
Its not hard (at all) to find hosting for either, the only reason in my mind PHP is harder is because of how beautifully PaaS works and that its free for small applications (good luck finding a reasonable free php host -- I know they exist but you'll have to dig through a whole lot of crud first)
The HN crowd is biased in favor of dedicated and virtual servers. But a very large number of mom-and-pop web pages and small business sites are still hosted on shared. That's what normal hosting means to a lot of people, and it's a market that developers of popular tools (like Drupal and WordPress) can't ignore.
Hosting isn't a very good metric in the first place. In a time where PaaS is going crazy and IaaS is crazy easy to find from tons of vendors, shared hosting is an out dated model that is only marginally a better option.
If you like Heroku, check out PhpFog.com or Orchestra.io. It's like magic too.
"PHP is not a good language" what is a good language?
To take your example, I do enjoy the feel of PHP, it feels natural to read to me, and after years of using it I rarely have to check the documentation for function behavior (such as array_merge...).
"...after years of using it I rarely have to check the documentation for function behavior (such as array_merge)."
This should not be something that takes years. I rarely have to check the documentation for similar Ruby functions after using it for only a couple months. After using PHP for 8 months straight, all day every day, I still had to look up almost every standard library function call - even if I thought I knew how it worked, I still had to check because the pervasive inconsistencies in the standard library ensured that I could never be confident in my guess.
(This is only the tip of the iceberg for why I don't like PHP and don't recommend people use it, for other reasons see: fatal errors vs. exceptions, the strange implementation of OOP (late static binding? isn't that an oxymoron?), and the numerous failing test cases / bugs that reveal themselves in every new release.)
Cheap, shared hosting used to be the greatest reason for staying withh php for me. But lately, I've been doing stuff that has required vps accounts, like rendering html to pdf or rendering pdf to png or powerpoint to pdf.
I realized I could just as well be using Erlang, as far as shared hosting support is concerned.
Now I'm thinking about switching to Python or Node. Or even Haskell.
That is not proper support for PHP, but they have had it in BETA for a while. Pagoda Box is the closest to Heroku around, it even does a lot of things much better.
" To be honest at this point in time I would say PHP is actually the hardest to find hosting for"
huh? Every VPS and shared hosting provider out there has PHP hosting.
"Whenever I develop in Python/Ruby I actually enjoy the 'feel' of the language,"
I use a language not because of its feel, but about what I can create with it. PHP is by far the easiest, most supported, and has a ton of real-world examples of sites getting millions of hits/day using it successfully.
"I can perform the same operations but generally theres far more cruft, and a couple manual lookups to see why functions behave differently when hashes ("arrays") have numeric indices (I'm looking at you array_merge!)"
I agree with you there. My one main gripe with PHP is inconsistent syntax/usage. However, I dislike frameworks like RoR because it is too high-level. I feel like I don't have enough power to do some customizations and when I do need to do them in something like RoR, I have to add hacks onto it.
// PHP is the easiest to find hosting for, to setup and to learn.
If you don't have PHP installed, it's probably the hardest to setup, much easier to install Java, Ruby (rvm), node.js.
To learn, the easiest language is the one you already know. I do believe PHP is a good language to start on if you have had no prior development knowledge, starting out with C like syntax is always a good idea, but certainly would like to thing complete newcomers would prefer the weaker more dynamic syntax of Ruby / Python.
Hosting wise, yes pretty much every server on the web hosts PHP, with the rise of platform as a service though, PHP lacks behind the other platforms offerings because of it's non-existant package management. PaaS is definitely getting a lot bigger, and takes all of the effort out of server administration, for newcomers I'd recommend PaaS, the learning curve for Sys admin is too high at the start. And in reality, heroku is one of the best offerings, just pushing up a Java app with a small dependencies file and everything gets installed for you, love to see PHP do that in the future, but in reality it just doesn't.
- PHP is still the best at generating web pages.
What?!
- PHP offers all the tools needed to build strong
applications (PHPUnit, xDebug, XHProf, ...)
Testing - PHP is probably the worst language I've ever written tests in, it is horrible compared to Ruby, Java, Node, Objective-C, C#. Other languages provider far better testing tools and debuggers. xDebug is horrible to setup compared to other languages where the debugger just works.
- PHP is not as bad as people like to say.
I agree with this point for sure, PHP 5.3 copes with most normal object oriented stuff, but so do all the other good languages for writing web applications, only the other languages have fantastic implementations, not "not as bad as people think" implementations. If this is one of your main points in recommending a language, that is shameful.
This absolutely does sound like a troll, despite the disclaimer.
I use Ruby sometimes, it sure is a lovely language. That doesn't detract from the fact that PHP is still the most largely used web programming language around.
I do development work in, consult about, get paid to write about and sell commercial products using... PHP. It has the biggest potential market for me so it has the most potential customers, the most potential readers and the most potential work.
Besides, even if you personally decide to switch to Ruby the PHP community will still exist and still suffer the same problems. Those need to be fixed, no matter what.
Please do not detract from a single topic with a random "PHP v Ruby" thread. I'm not surprised but I am disappointed.
The problem is that Ruby doesn't solve the package problem either. Gem and Bundler are a mess, and using something like rvm or rbenv to fix this is an even bigger mess (although it works).
If you really want to see something a bit different you'd have to look at npm and node which really buck the system by installing everything locally by default. The ability for different versions of the same dependency at different points in the tree is also pretty amazing. This is the direction that composer is going with it's included autoloader and similar package syntax.
If anything composer may go even one step farther by forcing you to document your dependencies in a manifest instead of allowing you to specify an individual installation via the install command.
Libraries, frameworks and tooling in PHP have evolved tremendously in the last couple years. If you look at the Symfony framework and its community you'll find a ton of brand new code that is state of the art, mostly inspired and building on top of ideas from other languages, most of the time improving on them too.
Node for example is lots of fun, but most of the libraries come complete with their bugs and lack of maturity. These are exciting things to work with, but not always best bang for the buck if you're aiming at being productive.
As for Ruby itself getting faster, well guess what PHP itself is getting faster all the time too [1]. You left it behind and it's still evolving without you. Shocker.
I've been writing PHP for the best part of 10 years and have started getting into RoR in the last year or so. It's hard, because I'm not a competent programmer. I wouldn't say I have much natural ability or spare time to learn new things as I have a full time job, run my own business and have a young family that demand my attention.
Luckily, my colleagues at the day job are supportive and through them, I'm slowly getting my head round Ruby, but only as much as the front-end stuff goes - starting a Rails project on my own would be a massive undertaking for me.
Given the choice, I'll do things in PHP because it's quicker and I have more experience on it. Jumping ship would be like abandoning 10 years of experience so I can start from scratch - I don't have the time to do that.
While python/ruby are arguable better languages in a lot of ways, they're also completely different and lacking in a lot of what PHP offers.
Everyone has their own languages of preference, and personally I really dislike working with python (not too much experience in ruby) while dealing with websites. I cringe each time I'm forced to check the manual for random function behavior, but its not enough to make me move over.
What I'm really looking for is an improved version of PHP. One that keeps most of its style but removing the backwards-compatible crap. It looks like HipHop may go down that path in the near future (they've already added python-style yield generator functions)
Literally the only thing that PHP has over Ruby/Python/whatever is ease of deployment. It is ridiculously easy to deploy a PHP application, whereas you will jump through a lot of hoops with other solutions.
After a lot of thought, I've arrived at the conclusion that this is because PHP has its request handler and template language all baked into the same process. It's pretty great at that - no setup required to start slinging code.
Other than that (which is significant), I'm hard-pressed to find an advantage. It's verbose, inconsistent, lacks features that've been present in other languages for years, and as the article author complains about, has no real vibrant packaging system for leveraging code re-use. Code re-use in PHP is "copy-and-paste". Yikes.
You could dedicate your life to improving package management in PHP and still never approach the quality of even RubyGems, let alone CPAN. Inertia is just too much to fight against when you have a massively popular language with an ad-hoc design that has accreted over a decade.
More power to anyone with a vision and a goal, but I'll personally leave PHP to its strength as batteries-included templating language.
We aren't in a competition against Gems or CPAN, in what world does that suggestion even make sense?
People use PHP and a package manager is needed to stop people constantly rewriting the same PHP. That means a package manager is required (we have a good one now) and support is required to take it forward (hence this post).
When will people stop the "RUBY DID IT" mentality and learn to get on with what needs to be done?
1. Build stuff.
2. Sell stuff.
3. Learn to make stuff faster.
While I do agree that there is a need for a real packaging system for PHP, I don't think Composer/Packagist is the answer.
Packaging is a real hard "exercise", I've dabbled with it, and it's certainly not an easy problem. Composer/Packagist is still not there yet and its ties to Symfony are "scaring" off developers (myself for example).
If it wasn't for the outdated code, the bad peer review system, PEAR is the closest thing we have, as PHP developer, of a working packaging system. If only the PHP team would invest a bit of time to modernize it and make it relevant again, I'd give it a go for sure.
So then you love projects like Pearfarm.com (mine), pearhub.org, etc? These are simply "open" PEAR repos a la RubyGems.
We use Pearfarm internally for all of our shared code, and it's super-easy to build and share packages.
Frankly I don't understand why something like Pearfarm hasn't been widely adopted, since it is essentially the same as RubyGems which is a completely workable solution for the ruby community.
I think people just don't understand that PEAR has 2 parts, the "installer" and the "official repo" and basically they write off anything related to PEAR.
In any case I'd love to hear your thoughts on why the community doesn't rally around Pearfarm, Pearhub, etc since they are basically the solution you're looking for.
The site needs a revamp but is there in concept. It'd only take about a days worth of time to give the site a facelift. You're missing basic things like completion of the additional instructions page.
I'd be willing to help. What are your thoughts on shifting gears towards Pyrus (PEAR2) moving forward? I'd personally like to start with the freshest of the fresh if I was going down the path of improving available package management options in PHP. My thought would be to create a wrapper around Pyrus to improve upon it.
The only ties to Symfony are the 3 small Symfony components we used to build Composer, instead of reinventing the wheel. We're trying to build a package manager that promotes code reuse and to keep everyone happy we'd be supposed to write everything from scratch? With mentalities like that, we don't even need a packaging system in PHP, everyone just writes their own everything and that's that.
Just give it a shot, forget how it's built, use it and please give us feedback/report issues. We're improving things on a daily basis.
To those wondering how tied to symfony it is, consider this:
It uses the process, console, and autoloader components. That being said, as a user, you need not worry about that. You put the composer.phar somewhere and invoke it.
If that isn't more useable than pyrus, I'd be interested to here what is.
> Thats idea is lovely and all but Flourish never made it out of BETA after years of development.
I'm happy to see Flourish getting some notice, even though there doesn't seem to be a lot of love for it with the small mention. I'm happy Flourish user for well over a year now, and I feel as if Flourish's BETA tag is akin to Google's BETA tag. I honestly haven't run across a single issue with the library that would discourage me from using it in a production environment.
It's an unframework, it doesn't force MVC, but you know what? I don't need MVC for 90% of what I do. What I need to do is validate form input, accept a few file uploads, log that to a DB, kick off a few internal emails, and provide user feedback.
I think that some day I'll dig into Code Igniter, but as the only web developer/designer in the marketing department for a small company a tool that lets me stay agile and do less than conventional setups, as well as easily integrate into existing environments has been a godsend for me. It smooths out a lot of PHP's weird quirks, comes pre-baked with an amazing focus on security (oh thank god for your passion for security, @wbond), and in general just helps me get my job done.
Oh, and when people ask me what framework I use, I say "Flourish, it's like jQuery for PHP".
/fanboy
edit: One downside to Flourish is that I'm almost useless without it. What do I use to sanitize a POST variable again? How do I unescape before output? I've gotten so used to the Flourish classes I spend more time on Google than coding when I don't have access to it.
I have of course seen that, but it doesn't fill potential users with much hope when they see it. I'm sure it's lovely, but in the scope of the article it is just not solving the problem unframeworks set out to solve.
It has also failed to keep up with progress, for example: fDate is basically the same as the recent DateTime object in PHP, as are many other classes now.
Your comparison of fDate to DateTime is a good conversation starter. fDate was built precisely to provide such functionality as DateTime does, but it works in PHP 5.1. DateTime is only available in 5.1 if you explicitly enable it. fDate means you can use sane date handling on any version of PHP without worrying about what exact environment the code will be run on.
If you dig into Flourish for a bit, you'll find that Flourish is basically aimed at being a portable, secure base layer to build stuff on top of. It gives you a platform to work in PHP one layer above the PHP functions that are largely derived from C libraries. It includes stuff like UTF-8 string functions, input filtering, arbitrary precision math and whole bunch of other stuff that will work with any kind of (semi-popular) DB on any platform with any version of PHP 5.1+.
Because of this, it isn't going to use PSR-0, or namespaces, or other new language features in PHP 5.3+. However, due to the architecture, you can successfully use it with PHP 5.3 or 5.4 and use all of the new language features in your part of the code. However, when you need to actually send a standards-compliant email with an attachment including UTF-8 content and inline images in the HTML version, fEmail has your back. Oh, and it prevents email header injection along the way. :-)
What problems does it not solve that the unframework concept is supposed to solve? I'm a but curious on what I'm missing out on, as I continuously feel like it meets or exceeds all of my needs.
An unframework is designed to give you a set of classes that you can use to build your site. Sure, on that level it works but what about when you need more?
At some point you need to have more classes, and where do they come from? One team of developers cannot forever add in more and more classes, that would be ridiculous.
If they allow other people to add in other classes they have an ever expanding codebase. If they dont allow developers to add in other classes then you are back to the original problem: where do I find new classes that will work with my code.
By using a package management system you distribute the workload to people who need a class, and so make it. People who have a vested interest (client project, some web service they are making, whatever) are responsible for working on a set of classes that really benefit them, like a payment library that works with Recurly, Spreedly, whatever. That should be made buy one developer, and a second developer could add in a new driver - instead of building the whole damn thing from scratch.
That is the approach package managers take, and they are much more useful than a one-man-army trying to build all the libraries.
Again if Flourish meets your requirements then great, but it certainly doesn't meet all potential requirements of the whole PHP community, package managers can with the "use whats there, build what isn't" approach.
Packages and frameworks are great, but they exist because they solve problems that core PHP doesn't solve well. That's why there are so many different ORM layers and databases classes and templating frameworks. For example PHP gives you the nuts and bolts to put together a database class, but there still isn't a good, reusable library I can plug in to my next web app without having to mess with details like handling exceptions for update operations and so on. (PDO is close but not there yet.)
Instead of centralizing a bunch of 3rd-party packages, PHP might better benefit by putting together a cleanly designed, optional, STL-like layer on top of the exposed nuts and bolts. Something like the powerful classes .NET provides. That way, a person could point to the official, well-documented, core-supported way of doing something like querying a database or subtracting two date objects instead of pointing to yet another "ultimate" PHP extension repository, maintained by who-knows. It might include things like rich database encapsulation, clean and obvious escaping of output for PHP's built-in template functionality, better datetime classes, and so on.
SPL is kind-of-sort-of heading in that direction, but right now it's more for things like iterators and lists--still nuts and bolts. PHP is building some of the stuff I described into the core--there's an equivalent DateTime class now, though it's still in its infancy, and PDO is getting closer and closer to being a pluggable database object. But we've still got a long way to go.
End the need for massive 3rd-party extension repositories and frameworks by building the necessary basics into the core. My dream would be to be able to have a PHP object library like the .NET ones. (Just the basics--DateTime, String, etc., not nightmares like DataGrid.) But I suspect PHP is too weighed down by its syntactical baggage and twisted history to be able to rise up to that dream.
> Packages and frameworks are great, but they exist
> because they solve problems that core PHP doesn't solve
> well. That's why there are so many different ORM layers
> and databases classes and templating frameworks.
This isn't just a PHP-centric problem. All the popular languages have package management tools that far surpass PHP's, with NPM and Ruby Gems being the most popular of the bunch. To say that packages and frameworks exist because core PHP is lacking isn't wholly correct. Packages and frameworks exist because they increase developer productivity and help to avoid recreation of the wheel on subsequent projects. While the concept of a STL-like layer is appealing, I fear it'd be hard to find widespread support. It'd be great to see the community get behind some core OOP libs for routing, request, response, auth, etc. The problem is the powers that be over at PHP.net are pretty set in their ways. This would have to be something that side-steps that altogether. The more approachable solution is to mimic NPM and Ruby Gems, allowing the community to help curate packages over github and decide which tools are appropriate for specific jobs via reviews, download counts, word of mouth, etc. It's definitely not perfect, but opens the doors for increased user contributions.
Anything that increases the friendliness and usability of PHP is a win for the community since the language isn't perceived in the greatest of light. The only way to combat the negative perceptions is to prove people wrong by making continuous improvements and keeping up growing web requirements.
Primative Objects for all basic data types would be lovely, but that is another "Wishlist Feature" that may or may not happen at some point.
The point of this article is not "What languages should PHP copy to get better", I am talking about "What PHP developers can do today with the available tools to fix things for tomorrow".
PHP has everything it needs to move to a more package-based way of working, it just needs the community to take it up.
But I think it's exactly these "wishlist features" that make frameworks/packages a necessity in the first place. If PHP had these functions well-implemented and -documented in the core, it wouldn't be necessary to have 10 different flavors of PHP frameworks and packaging systems. That's why you don't see any (or very few) 3rd-party .NET frameworks.
Instead of the community fragmenting again and creating yet another packaging system, the community should contribute directly to the PHP core to eliminate the need for frameworks and package galaxies in the first place. (Though packages would still be useful for lesser-used or shiny and new features.)
Is that practical given the political and code state of the PHP core? Maybe not. But I guess that's why I called it a "dream situation" in my OP.
I think you misunderstand. Packages are not built to fix missing features in the core of a language, they are built for everything else.
OAuth, Authentication, Twitter API interaction, ORM's and all that jazz. None of that fits into the core at all.
You say that if the core of PHP got better then we wouldn't need MVC frameworks? What about things like ASP MVC? PHP is a language. A framework is an architecture that allows websites to be built in a certain way.
Building Composer is not "splintering by building yet another package manager", it is building the package manager we never had. Barely anybody in the community uses PEAR (I have met one PEAR developer ever, and I meet a lot of PHP developers) and there are not other existing options that work.
Composer works, so the more packages can be made generic and reusable instead of just depending on one framework the better it is for the whole community. This is the only way to reduce splintered efforts.
That is all entirely beside the point of "Adding various new good features would be good". Of course it would, but I'm not talking about trying to make every PHP developer learn C and send a pull request. That is outside the scope of this article.
Very interesting! Are you thinking something more along the lines of Python's "batteries included" style standard library?
Also, it'd be great to move away from PHP's functions-in-global-namespace style standard library, towards having a set of more well engineered core OO libraries. The first examples that come to mind are: OO strings and collections libraries. I'm thinking along the lines of Ruby's Enumerable.
That is what PHP are doing, but slowly. When features are added they are often as PECL or included as classes, and not as proceedural functions.
Moving forwards it seems like PHP is making the right calls, but backwards compatibility is important to the project as PHP has more legacy code than any other web language. That doesn't mean it's dead, it just means they can't say "sod it, lets re-write everything overnight".
ZF is yet another framework, and a fairly complex-to-setup one as well.
Problem is that when a newbie searches for "how to query mysql in php", they get 100 different tutorials doing it 100 different ways using the core functions. You won't find one using ZF unless you look for it. By the time a newbie is done digesting a mountain of tutorials, they realize that they need a framework, and they either build one of their own or turn to a 3rd party one. (And ZF doesn't seem to be the most popular one either, outside of the corporate environment.)
Having a clean object library in the core would go a long way towards eliminating the very need for a framework like Zend, and give newbies a place to go for guaranteed development and documentation instead of being at the whim of a framework developer.
It's a little unfair of a comparison as .NET was released at the same time as C#. So C# never got the chance for little incorrect "how to query mssql in C#" articles.
But I agree, whatever ZF original intention, not being simple and in-core is unfortunate.
I never found ZF difficult to setup, its a core part of a lot of the PHP work ive done...not saying it solves this problem but i am surprised people find it hard to use.
I definitely agree that Composer/Packagist are the way forward for PHP, and they are gaining momentum and support. What always helps is solid documentation, which seems to be coming along. There's now a site up at getcomposer.org with info about the Composer file schema and usage, which will really help frameworks looking to adopt it.
It appears frameworks can implement their own package type handlers, and specify alternate target directories, which goes a long way towards making it possible to integrate it with their own package formats.
I can see in a year or two's time the standard across PHP apps and frameworks becoming "add this add-on to your composer.json and install via `composer.phar install`"
> The nail in the coffin for me with PEAR is one of the biggest bug bears of the Gem system: system-wide installation. If I want to use a specific package, which requires a newer version of an already installed package, then I have to update it on my whole installation. That means an application I have not touched in weeks might break next time I try loading it on my local box. WAT?
No, you don't. You can have a system wide installation, but you can also install local copies that are just used for certain apps, and it can be managed using pear.
I think the #1 barrier to the use of packaging systems in PHP is the fact that, even nowadays, the lion's share of PHP apps are hosted on shared hosting.
In shared hosting, you don't have the ability to add system-wide packages. Good luck asking the hosting company to add arbitrary packages in any language. You might not even have a proper shell. There are a billion security issues to take into consideration when you try to access anything outside of your home directory. There's no standardization whatsoever about where to put files that don't need to be publicly accessible, though you could argue that cPanel's monopoly offers a quasi-standard. It shouldn't come as a surprise that just-upload-the-whole-damn-thing-yourself is the default method of deploying PHP packages and libraries.
You could come up with the best packaging system to use on your own server, but you won't be able to get any popular apps and frameworks to adopt it as long as those apps and frameworks need to support shared hosting customers. Shared hosting needs to be fixed before you can have a packaging system for PHP that is as powerful as npm, gem, and easy_install.
I'll only speak for Composer which is a new-ish PHP dependency manager, because I'm the co-lead on the project.
System-wide packages are a massive pain, especially on shared hosts. That's why we took the approach of installing everything local, much like virtualenv or npm do. You get your dependencies for the project, in the project. Upload, done. It comes with an autoloader to load classes and it all works with relative paths, so moving it all around is no problem.
Obviously this only handles php libraries, not apt-get packages or whatever, there are tons of great tools for managing system configuration, and we did not set out to reinvent those. But php libraries can just be downloaded, a few of them might depend on specific extensions but mostly if you have a recent-ish PHP version stuff works on most shared hosts worth their name.
As for your point on adoption, I beg to differ. Symfony which is one of the largest frameworks will use it in it's upcoming 2.1 release, I know of a few other frameworks that are looking into it, many libraries are already made available. Even major apps like Drupal have been looking into using it, not for their plugins at first, only for their own dependencies, but once they also discussed the adoption of it for plugins, and I know a few other CMSs have looked at it for just that, because it's easy to wrap into a web frontend to manage installation of dependencies from anywhere. I'd even argue you could convert an entire ecosystem if you have it all in one controlled database already, generating package metadata on the fly and installing from existing sources, then giving the option to plugin authors to start requiring other plugins and plain libraries instead of bundling everything in their code.
Composer is quite new and it's definitely not widely adopted yet, but things are looking way brighter than you picture them. Given the ease of use of publishing packages (basically you have to write one package definition like in npm, and then for a new release you just have to git tag and push to github), resistance from people should be pretty low. Please see docs on http://getcomposer.org/ if you are curious.
Thanks for the clarification. I guess I was a bit too negative in my first comment.
I'm all for composer if it's going to make library management easier at any level, either local or system-wide. Maybe if several well-known frameworks agree to standardize on composer as their plug-in manager of choice, you may even be able to obtain a de facto monopoly on PHP package management, and that'll be a good thing for all of us. (I'd love to see some sanity in WordPress plug-in management, too, but I guess that's a tall order.)
I just wanted to remind people that as long as you have to make concessions for the current state of shared hosting, you will hit limits at one point or another.
Anymore, I consider system wide package installation to be a liability, not a feature. The whole point/purpose of npm or composer is local installation. Look at the mess of Gem/Bundler and then you have to factor in that rvm and rbenv are basically designed to isolate system wide installation because of the problems associated with system wide installations.
Sure, you can get part of the benefit even if you're on shared hosting. (Off-topic but related example: I use git to manage projects locally even if they are going to be deployed to a server that doesn't support git. Last week I finally moved a small-business client to a git-enabled host, and it was such a relief.) But it's only part of the benefit.
A good packaging system, for example, will track your PHP version and extensions and make appropriate adjustments. But what if your host uses a slightly different version of PHP with a slightly different list of extensions? At best, the packaging system makes adjustments again, and you cross your fingers hoping that nothing breaks. At worst, everything breaks because your host uses the wrong version of GD or whatever.
Every shared host that supports Ruby gets mired in requests for and complaints about specific versions of gems they've installed. I don't think it will be any different for PHP.
The problems you mention are why user land components should be used where possible and wrap builtins. Install the components local to the project and you control the outcome.
What is broken here is surely package management in general?
I'd like to use one tool. If you don't want files system wide - then perhaps that should be an option in the package management system.
It would seem silly and wasteful to have dozens and dozens of the same packages languishing on the same computer. So part of me thinks this needs to be handled at the filesystem level.
Or there should be a way for package managers to speak to each other. How about throwing something like apt-get and dpkg out and replacing it with something better - that can handle Gems, Python libraries, etc?
One big problem with PEAR is that PEAR hasn't tracked changes in the PHP language. You can't expect that packages from PEAR will work in a recent version of PHP if you don't set the warning levels very low and enable the backwards compatibility settings that you really shouldn't.
Seven paragraphs about how every attempt at code reuse in PHP ends in failure followed by an exhortation for everyone to gather round for another go? Are we sure this isn't satire?
Like many Ruby developers, I left PHP because I saw the kind of stagnation the author describes at the beginning of this article. I saw lots of good ideas originating and flourishing in the Ruby world, and sometimes trickling back to PHP. I saw a more well-thought-out language that seemed worthy of all that attention. So I hopped.
The libraries and library management tools and frameworks available to me now are awesome. Ruby itself is getting faster all the time. Is there really any reason left to stick with PHP other than inertia? (I don't mean that dismissively; if you have a massive existing code base, that's real inertia and changing would be a tall order.)
You can substitute Python or Node or whatever for Ruby here, but my point is: why fight the uphill battle to bring good tools to a language when other languages already have them?