Poor PHP. It’s so lonely and unloved these days.
Well, maybe not lonely – it still undergirds Facebook, Wikipedia and WordPress, amongst a fair number of others. But, certainly, unloved – and not without some justification.
Despite working primarily with Python and Node on the server-side in recent years, I’ve always had a soft spot in my heart for PHP – I don’t actually like it, but I tolerate it for its good points, the way you would an eccentric uncle. PHP was the first web-oriented language I learned, and the thrill of the quick iteration it allowed, when coming from a C and Java background, was not to be denied.
That said, I must still admit that PHP is, to put it nicely, something of a mess.
The problem has always seemd to me to be that its being designed by committee – and one that has a difficult time agreeing on standard conventions, or what other programming language they’re trying to ape. Most of my aggravation, petty thought it may be, still stems from its inconsistent function naming (does any given function use_underscores, camelCase or justsquishwordstogether? You won’t know until you take yet another trip to the documentation). It also suffers from not being sure whether it wants to be functional or, post PHP 5, object-oriented, and ends up with a sometimes awkward mishmash of the two.
Now, there are any number of programmer posts lamenting the state of PHP (usually written in the aftermath of a painful struggle with some complex legacy project); and most would attribute (or blame) PHP’s continued dominance of a large percentage of projects to momentum and availability, rather than being in any way ideal.
I would tend to agree.
The winds of change are blowing though, slow but steady. Instead of yet another condemnation, let’s look at some of those recent changes that might mean – whether weighing a rewrite versus continuing to use PHP for a legacy project, or even choosing a server-side language for a brand-new project – PHP might once again take a place amongst the options.

PHP-FIG

There’s a lot of talented programmers working in the PHP ecosystem (whether they like it or not), and some big projects filling needed roles. Getting them all to work together would be a huge job – ideally, one that all of the projects involved would cooperate to bring about. For once, the ideal is actualized in the PHP Framework Interop Group.
Their page starts with a disclaimer that the standards they propose are not necessarily intended for the PHP community at large; but language-wide standards (for coding style, logging and autoloading right now with, I expect, more to come) are exactly what PHP needs.
The autoloading in particular. Importing a library is blessedly easy in Python:
[code lang=”python”]
from wherever import whatever
[/code]
Accomplishing the same in PHP requires some effort to ensure the appropriate source file is included/required before you attempt to reference it in any way. But, if you conform to the autoloading standard, you can just plop at the top of your controller:
[code lang=”PHP”]
use wherever/whatever;
[/code]
For love of all that’s good, if you’re writing a PHP framework or library, conform to these standards! It will make your target developers lives easier, and make your library easy to discover and adopt.

Composer and Packagist

Ah, but how do they discover your library? In keeping with PHP’s strong tradition of cribbing from other language’s notes, Composer and Packagist would be familiar to anyone who has worked with Node and npm.
Allowing you to specify the name and versions of the packages you need in the familiar JSON format, composer will automatically download the appropriate packages to a psr-0 or psr-4 compliant structure and generate the autoloader for you to use, making adding other libraries to your project almost painless. Its not sparsely supported, either – Symfony, Doctrine and other big names are available, along with 20,000+ others.
Composer can offer autloading of libraries and frameworks that aren’t psr-0/4 compatible as well, along with a number of other capabilities and options. It plays nice with phing for your build process, if you so desire. Give it a look.

HHVM

The Hip Hop Virtual Machine has created some buzz even in the corners of the net most hostile to PHP (ie. anywhere you find a large number of programmers). Improving the performance of PHP is a worthy goal in and of itself, of course – although it’s not yet ready for prime-time, from the figures the hhvm team has posted, it looks like we’re well on our way to having a powerful replacement for the Zend engine.
That said, the real reason I’m excited about having a JITing virtual machine that’s 100% compatible with PHP is that we may never need to write PHP again (and we may live to see the end of posts griping about it, as well).
What’s that you say? – after all this argument as to why PHP might deserve a place at the table, here I am arguing against it? But remember – I don’t actually like PHP; the previously mentioned standards and easy access to libraries can make programming in PHP much more tolerable, but can’t fix elementary failings of the language. But being able to target the HHVM the way Scala, Clojure, Groovy et al. target the JVM would allow each programmer to pick the language that suits them best – and still get the benefits of easy deployment and compatibility with existing code and libraries.
That would be the best of all worlds – all of PHP’s strengths without any, well, PHP.