Tobias Schlitt describes Tim Bray’s talk at the International PHP Conference. (PDF slides) Tim compares PHP, Java, and Rails along several dimensions. One of those dimensions is maintainability. Tim ranks PHP as least maintainable, Rails in the middle, and Java as most maintainable.
This is not a surprising ranking. After all, Tim is from Sun, and the maintainability complaint is common in Anti-PHP rants. I’m not trying to suggest that Tim is anti-PHP, far from it, it seems. I’m just using his ranking as a spring board to ask questions.
Chances are that your average Java jockey or C scientist’s first exposure to PHP is to download one of the popular PHP applications. These are usually the product of some open source mega-project with developers of varying degrees of skill. Our engineer-by-day spends a few evenings with the program. The code is not technically outstanding.
How can something like this be so popular he asks? Yet, the software is successful by definition. Nobody downloads unsuccessful open source applications. The technocrat, heavily invested in his own technical prowess, faced with successful yet technically inferior code experiences cognitive dissonance. The only thing to do is to belittle the successful, but surely offensive code. “I could write better code than this,” he says, or “this code sucks,” or “this is unmaintainable.”
It is easy to dismiss these gripes inside the PHP community. After all, those of us using PHP professionally can write maintainable code in PHP. Ask any programmer and they will tell you, “My code is maintainable.” Who writes all of this unmaintainable code, anyway?
Lets take this gripe at face value for a moment. Why is PHP code considered hard to maintain? Is it the language that produces code that is hard to maintain, or is it that the popular ambassadors of the language happen to be programs that are hard to maintain?
Another common PHP sucks complaint is that PHP doesn’t scale. When you are talking about traffic, there are all sorts of counter examples for this. Personally, I’m dying to learn the story behind those .php extensions on YouTube. But, this post is not about requests per second.
Another kind of scalability is team size. I think that when some people complain that PHP doesn’t scale, what they mean is that PHP doesn’t scale to large development teams or large projects. Now we are back to the maintainability issue.
What is it about PHP that makes people think that it is not suitable for larger development teams?
The criticisms of maintainability and scalability generally come from outside the PHP community. But, there is a common complaint from within the PHP community.
It is hard to find a PHP wish list that doesn’t include namespaces. It comes up again and again.
Sometimes users request a feature without explicitly making their true desires and intentions known. They say “I want feature X,” but what they really mean is “solve problem Y.” Good programmers can hear the request for X, but make the jump to solving Y.
When people ask for the namespace feature, the problem they want to solve is integrating code from multiple parties. I wonder if the frequency of this request is a signal of a problem in this department? Perhaps one that requires more than just namespaces to solve? Is the namespace request a proxy for a larger problem?
What is it about PHP that makes it hard to integrate code written by multiple parties, whether they be different developers or different organizations?