Why modern programmers hate PHP

I’ve been grudgingly using PHP for the last 9 years and in that time I’ve read countless criticisms and rants about the language. I’ve heard it all- inconsistent parameters, global function cesspool, poor OO support, lack of modern features (and the list goes on). You name it, I’ve heard it, thought it, and sworn at it.

Everyone loves to hate PHP- and rightfully so, it’s without a doubt an unorganized and poorly designed language- but I think there’s one point which all of the PHP critics are missing.

It’s not the language, it’s the tools

Raise your hand if you used node.js. That’s great- node is a really cool (and popular) technology. But Javascript is similarly as inelegant as PHP (although, not quite as bad). Why don’t node (and javascript) see as much hate? I’d argue it’s because even though Javascript isn’t the prettiest fish in the sea, it still has a decent set of tools- including a reasonable package manager. But even if PHP did have nice tools (it doesn’t), there isn’t really a great way to share them.

But, what about PEAR?

PEAR is a fundamentally poor platform for sharing PHP packages. If anything, it’s a place for poorly written code to die. How many packages on PEAR have been published and not maintained? How many are written in using the antiquated PHP4 syntax? The answer is alot. But why is it so bad?

Packages need to be proposed, approved and voted in by committee

You can’t create something cool and instantly make it available like you can with gem or npm. A skilled programmer isn’t going to waste 5 hours of his time pitching an open-source library to a committee that may or may not turn it down. We have better things to do with our time.

Competing packages are not allowed in PEAR

Know that rotting PEAR package that’s been sitting untouched for 5 years? Guess what, you can’t submit a similar package. Innovation is fueled by tackling problems in new and interesting ways- build a car, not a faster horse. Oh and no frameworks too.

Packages need to adhere to the PEAR coding standards

And boy are they nitpicky. Don’t even bother if you close your comments the wrong way- your code, which you spent hours refactoring to meet PEAR’s naming and design patterns, will be held back until it meets all of PEAR’s style guidelines. Hope you don’t use tabbed indentation, ‘cause that’s not allowed either.

You need to use their SVN repository

npm and gem are pretty much version control and code host agnostic. With PEAR, you have to use their SVN repository with equally terrible doc viewer and bug tracker. These would have been poor tools in the 90s. In 2012, it’s just embarrassing.

Don’t PEAR Channels fix all of that?

In the most cut-and-dry sense, they do- you can even use GitHub Pages to publish the XML clusterfuck that makes up a PEAR channel. But it’s fragile and a huge pain in the ass for the package maintainer. Getting new packages means hunting down the correct channels and cross-channel dependencies are a nightmare.

Gem and npm are magical because the path of least resistance is to share your code with the world.

So, what’s the solution?

PEAR has a new project called PEAR2/Pyrus with absolutely no documentation. From what I can tell, it’s the same boat as PEAR but with a prettier face.

I’ve just heard about a new project called Composer (with companion site Packagist) that is a really great start to tackling this problem. The question is- can something like Composer compete when its biggest competitor is backed by the language itself?