PHP Sucks

My work on a tool to migrate Drupal content to WordPress’ eXtended RSS (‘WXR) led me into some dusty corners of the WordPress codebase, and I’ve been meaning to write a grumpy post about how much I hate PHP (in which WordPress is written), but Jeff Atwood at Coding Horror beat me to it with his own PHP sucks lament. Like me, Jeff wonders at the success of PHP given what a dreadfully sucky software engineering tool it is, and scratches his head at the many major Internet properties (Wikipedia, Digg, and WordPress among them) which are successful notwithstanding an implementation in a language a VB6 programmer might reasonable call “shit”.

Interestingly, though, Jeff and I arrived at two different conclusions on the matter. Jeff surmises:

Some of the largest sites on the internet — sites you probably interact with on a daily basis — are written in PHP. If PHP sucks so profoundly, why is it powering so much of the internet?

The only conclusion I can draw is that building a compelling application is far more important than choice of language. While PHP wouldn’t be my choice, and if pressed, I might argue that it should never be the choice for any rational human being sitting in front of a computer, I can’t argue with the results.

You’ve probably heard that sufficiently incompetent coders can write FORTRAN in any language. It’s true. But the converse is also true: sufficiently talented coders can write great applications in terrible languages, too. It’s a painful lesson, but an important one.

Hmm. I came to a different conclusion. Though I don’t know any of the programmers at the major PHP-powered properties, I have looked at some of their code, and I must say it does not look like the product of talented software engineers making due with a shit language; it looks like cruft bodgered together until it works, as though the last twenty years of hard-won software engineering advancements never happened.

To take but one example, I am working on some code that exports a Drupal site in WordPress’ WXR format, which is basically RSS with some additional WordPress-specific elements thrown in. Of course the format isn’t documented at all, so I set up a simple WordPress site, wrote some test posts with attachments and comments and whatnot, exported the site to WXR, and used the resulting WXR file as an example upon which to base my own implementation. I’ve mostly got it to work now, but I ran into some troubles along the way due entirely to the poor construction of at least the WXR import portion of the WordPress codebase.

To start with, WXR, like RSS before it, is an XML format. XML, having been around for over a decade now, is a very well-understood format. One of the fundamental principles of XML is that whitespace doesn’t matter. You can put text right after a start tag, or on the next line indented with a tab, or after several blank lines, and it will parse just the same (some exceptions but bear with me). I foolishly assumed that since RSS uses XML, and WXR extends RSS, that I needed only produce XML that was structurally identical to the WXR sample I had, without regard for whitespace. When I imported the first WXR file from my tool, WordPress didn’t complain but I noticed none of my content was coming through. WTF?

I then cracked open the import code at wp-admin/import/wordpress.php. Once there I stared in horror as I realized what they were doing. Rather than parsing the WXR file with, you know, an XML parser, the author of this particularly craptastic bit of code used a regular expression to find certain tag pairs, hard-coding the namespace prefix and assuming no whitespace between the start tag, content, and end tag. Super!

Not content merely with a gobsmackingly vile solution to a problem solved 10 years ago by the XML DOM, the code does neato things like injecting local variables into the local namespace non-obviously with calls to helper functions, and performing what amounts to zero error handling. For example, there was a bug in my stuff that migrated blog posts with a type attribute of blog, when it should have been post. Strangely, the import into WordPress ran without error, but none of the migrated blog posts showed up. Curious, I looked inside the WordPress MySQL database, and found all of my missing posts there; they just weren’t showing up. Rather than sanity-check the WXR input, the import logic just sucked it dutifully in, so future queries for type='post' would happily skip over my content without so much as a peep.

While I do have some sympathy for those unfortunate bastards who must work with a shit tool like PHP, I know for a fact that it’s not impossible to engineer quality code with it. If you doubt me, download the source tarball for Gallery 2 and find out how the MVC pattern, unit testing, and object orientation are indeed possible in PHP.

So what to make of this? I don’t think software engineering quality has anything to do with the success of a piece of software. Pristine, gleaming, perfectly coherent code doesn’t seem at all correlated with success, and clumsy bodgered-together cruft seems the rule and not the exception at the top of the software pile. Can you find well-engineered software that was successful? Sure. Can you point out spectacularly monstrous code that failed? Even easier. But explain to me how crufty software like Mediawiki and WordPress can be such runaway successes while Gallery and Drupal remain relatively obscure, if software engineering quality is so critical to success?

Now don’t get me wrong. I’m not one of those backward types who doesn’t see the point in unit testing, thinks object orientation is too complicated, and wouldn’t know a bad code smell from roadkill. I take the practice of software engineering seriously, and strive to build the best software I can within the constraints of our business. In this regard I’m more like the second stonecutter in Peter Drucker’s Three Stonecutters parable:

A favorite story at management meetings is that of the three stonecutters who were asked what they were doing. The first replied, ‘I am making a living.’ The second kept on hammering while he said, ‘I am doing the best job of stonecutting in the entire country.’ The third one looked up with a visionary gleam in his eyes and said, ‘I am building a cathedral.’

The third man is, of course, the true ‘manager.’ The first man knows what he wants to get out of the work and manages to do so. He is likely to give a “fair day’s work for a fair day’s pay.”

It is the second man who is a problem. Workmanship is essential; without it no business can flourish; in fact, an organization becomes demoralized if it does not demand of its members the most scrupulous workmanship they are capable of. But there is always a danger that the true workman, the true professional, will believe that he is accomplishing something when in effect he is just polishing stones or collecting footnotes. Workmanship must be encouraged in the business enterprise. But it must always be related to the needs of the whole.

… The tendency to make the craft or function an end in itself [in future] will therefore be even more marked than it is today. … The new technology will need both the drive for excellence in workmanship and the consistent direction of managers at all levels toward the common goal.”

I don’t accept that disciplined software engineering is equivalent to “stone polishing”, but I think the point is that past a certain qualitative point (which is different for each activity and each situation) improvements in workmanship don’t contribute meaningfully to value in the marketplace, and if undertaken at the expense of other activities which could have increased value can actually result in a net loss of productivity.

From the success of WordPress and Mediawiki and Youtube, I think it’s hard to make the case that more time and resources should’ve been spent architecting and writing better PHP code, but I don’t know how one can determine a priori where the productive labors stop and the stone polishing starts. If PHP has one thing going for it, it’s that it makes anything but the most cursory stone polishing so clumsy and uncomfortable that only the most pedantic of programmers would bother. Make of that what you will.