Coyote Tracks

(See a followup posted December 20th.)

You may or may not know I’m an (underemployed) web programmer. I’m mostly “back end,” which means I mostly program the server, not Javascript or Flash. Over the last year “front end” has become very hot–if you merely know what AJAX stands for, you may get interviews for $100K+ positions–so I’d be better off positioning myself as a front end developer, but I haven’t yet because I’m stupid.

I prefer Python, but I mostly use PHP, the language nearly every web developer learns first. PHP is to the web what Visual Basic is to Windows, but even more so: a powerful enough language to do nearly anything you want, ubiquitous, easy to get up and running (on many web hosts it’s pre-installed), and forgiving of shitty code. It started as a set of scripts written in C¹, but over the years has turned into a huge, shambling mutation. What nearly all other languages have in libraries PHP shoves into the language core, often in multiple incompatible ways. Nearly identical functions take parameters in different orders, the function naming scheme is “whatever the programmer liked that day,” and the language’s very design lends itself to gaping security flaws (deprecated, but faithfully retained for backward compatibility).

Recently, PHP has gathered its own set of MVC frameworks similar to Ruby on Rails and Django. This makes sense, until you think about it deeply. See, Rails is a framework for making Ruby a platform for web apps, and Django is a similar framework for Python. Such frameworks exist because most languages weren’t designed for the web from the start. PHP was. PHP is, in itself, a web framework.

Yet we’ve learned a lot about how to make web frameworks over the last decade, and we want to bring that to PHP. Hence, frameworks in PHP! But by building frameworks on what is itself a (bad) framework, instead of fixing poor design decisions from way back when, we stuff our new framework full of workarounds. As fine as the emperor’s new duds may appear, they’re a tacit admission that PHP, as we head into 2012, is no longer very good at the one thing it was specifically designed for.

These irritated thoughts are brought about by a client migrating to Symfony 2 and embracing PHP versions of things the cool kids are using with Ruby and Python. We can have automated deployment and migration and package management and “NoSQL” and everything you guys have! Just uglier and weirder. Symfony 2’s coders are doing everything as right as possible, and that’s probably true of most of the other mysterious floating bits in the gumbo our new de facto chief architect has cooked up. But we’ve still ended up with a mishmash of patterns from Django, Rails, and enterprise Java, all held together by melted licorice jellybeans.

I’ve spent the day–I now suspect needlessly–setting up an Amazon EC2 instance to mirror that architect’s own dev setup, as it appeared I’d lost the wrestling match on my local machine with PEAR and PECL² and Symfony’s own dependency management system. (Data point: his development environment requires tools written in Python and Ruby.) Actually, the problem today came from that dependency system; my local machine is just fine, but now I’m too tired and annoyed to actually do the programming I’d intended to start when I sat down at 9:30 this morning. I understand this is just one example, but if you compare any PHP web application of any measurable size to a similar Python or Ruby application, it’s hard not to come away with the impression that the PHP program is struggling to do things that just aren’t that tough in the other language.

While I’m happy to see PHP start getting “modern” language bits (you Lisp hackers, stop snickering), the more I’m exposed to modern PHP in practice the more I think it’s doomed. It’ll keep coasting for a few more years, but if I were in my mid-twenties, I wouldn’t be banking on it. I wish I wasn’t banking on it now. This could still be turned around if the PHP dev team would show the brass balls that the developers of Python 3, Ruby 2 and Perl 6 are showing in cleaning up their respective languages–all of which, frankly, need far less cleaning up than PHP does–but I don’t think they will. If there’s any design philosophy self-evident in PHP, it’s one of avoiding bold moves at any cost.

A friend compared PHP to the COBOL of the web, and indeed, that seems to be COBOL’s philosophy, too. Yet that philosophy has served COBOL pretty well: it’s (still) being used fairly widely in the kinds of business applications you (still) run on minicomputers and people who know it (still) command a good salary. I don’t think PHP is going to have it nearly so good ten or fifteen years from now.

Oh: “Asynchronous Javascript and XML.” Go get a new job. You’re welcome. At least I learned how to set up an EC2 instance, right? I’m going to go learn COBOL now.