Hacker Musings and OCD

The Last PHP Discussion Ever

I’ve always sort of had a love-hate relationship with PHP. I think a lot of people do. It’s a tremendously enabling platform – it ships on Linux and Mac OS X and has plenty of Windows support, it’s pretty easy to enable, and easy to pick up. On the other hand, it can be immensely frustrating: until version 5 it shipped with some of the most idiotic defaults and compared to other more traditional programming languages, it has some … rough edges.

Like my loud-mouthed tech types, I had written – over and over and over – The Definative Takedown of PHP. Epic in scope, so powerful and compelling Rasmus himself would give a tearful apology to the U.N. for unleashing this abomination on the world; Terry Chay would be so moved he’d devote the rest of his life to writing quines in Ruby.

Of course it was never perfect, and under constant revision, I never published it.

And, as much as I complain about PHP, I also began to outgrow hating on it. I came to a certain type of acceptance of PHP. In doing so, I realized all that frothing anger about inconsistent function arguments across the standard library was not the reason I was so annoyed at PHP all the time.

I finally pinned it down to one thing; one thing that summed up my annoyance with PHP, both in our enterprise and in the world at large. It is this:

PHP gets chosen “by default” because of its strengths, and its weaknesses are not only ignored, they are not accounted for in said choosing. By the time your devs and ops may be having issues, you may be in a position where weaknesses now outweigh strengths, but you’re too invested in PHP to reconsider. You chose it because “we’re a PHP shop”, not because you objectively weighed pros and cons.

I think the “state of the art” of PHP, as I write this, is generally worlds apart from what the bulk of the PHP community actually use as development practices (although I think this is changing).

In many ways it looks like PHP wants to occupy a kind of Java-esque place; it wants to be Java, but without the compilation step, and with a better deployment story, and without the complexity of things like JNI and RMI and all that stuff. And that’s great. There’s nothing at all wrong with that.

But it means that you (probably) need to employ some sort of of different practices. The hacky front-end your intern coded up is probably not going to be what you’ll want to base a product on; you may think he’s rapidly innovating now but the devil’s not just in the details, it’s support, maintenance, and ongoing development.

This is not to say that purely effective PHP means total object orientation, but it’s clear OO is the way to go. There will probably never be a day in which PHP is OO-only – the procedural functions will probably always remain – but the state of the art, and all the time and emphasis, seems to be pushing towards OO as the preferred way of writing PHP code of any size and complexity.

Likewise, you probably need to think about how to best write code like that. You’ll probably want unit testing. You’ll probably want to do some sort of continuous integration. You’ll probably want to make sure your source control is really working for you. You’ll want to explore the SPL and start thinking about creating Iterable classes instead of endlessly looping over array slices. You’ll want to use a framework. You’ll probably want MVC. You’ll want to seriously and with some rigor, constrain your use of the standard library. You’ll want to design for security.

It may be nothing like how you work today, and almost certainly isn’t how the intern whipped up the thing you think is awesome.

And not everyone needs all these development methodologies. Unit testing is a good idea, but the degree to which your enterprise does unit testing is probably entirely an internal decision. Not everyone favors a rigid source control system. But if you’re not doing any of them? Switching to Ruby won’t save you but let’s face it: you’re not exactly gaining anything by using PHP. ‘Agile’ is more than shitting out some code quickly.

PHP is not entirely suited to every possible task in the world. It does not excel at writing daemons, or perhaps doing high-performance computing. As an example, I wrote a script in PHP to do an import of some XML – over 35,000 individual XML files, each being read, parsed, and doing a large number of database operations. It took about 4.5 hours and used 110% CPU and a lot of memory. I rewrote it in another popular scripting language, and cut time own to under an hour and CPU usage to about 90%. In another case, we learned that a certain application had implemented its own crypto rather than make the user compile any extension. This meant in practical terms, it would only ever be but so fast; each page load did this crypto BS. Had it been done with the C extension it would have been orders of magnitude faster.

This is a knock against PHP only in the sense that we had to make the call: step outside the PHP garden, or accept its limitations. Some were upset at the idea of having to have this component not be written in PHP, but that’s back to my central point: you must accept that the most ideal PHP architectures are probably loosely coupled and front-end oriented.

I tweeted the other day that “canonical” PHP was actually shockingly productive. And I think it’s true. PHP gets a bad rap from a lot of people, because they expect things out of it that it never really promises.

Make a responsible choice. Be willing to openly discuss its downsides and things that are possibly wrong with it, especially if you’re a PHP shop used to working in the PHP4 paradigm or with PHP4 applications from an ops perspective. “It’s a web app and we know PHP” isn’t the end of the discussion.