Good apps, once built, tend to be in production for an astonishingly long time. Which means that they have to be maintained for an astonishingly long time. Which means that maintainability is important. There are a lot of things that go into maintainability, but I suggest that the biggies are object-orientation, MVC architecture, code readability, and code size (less is more, a lot more). This is PHP’s Achilles’ heel, of course. Yes, it is possible to write clean, object-oriented, modular, MVC-style PHP applications. But most people don’t; the majority of apps that I’ve seen have spaghetti PHP code wrapped around spaghetti SQL embedded in spaghetti HTML. Also, a lot of the people who really understand O-O and MVC and maintainability would rather work in Java or Rails.

This observation couldn't come at a better time - especially after I spent an evening mashing at the keyboard sharing in my experience trying to get some PHP sample code to work.

I am not a PHP-hater by any account. Hell, I choose PHP for a lot of my web work. But there is no getting around the fact that the incredibly flat learning curve for the language naturally leads to a lot of code written by amateurs. That code then gets contributed to open source directories, promoted on blogs, and/or in Pear and then gets included in other people's applications because it is generally the case that most developers will just integrate carte blanche any open source code into their application if it solves their problem. If you are a developer reading this, let me ask you, when was the last time you audited the code you downloaded from Pear or CPAN or Sourceforge?

This is of course at the heart of why PHP has developed such a bad reputation among security experts. Amateur developers by their very nature don't have the experience or knowledge of how to write solid code #, and thus tend to write code that does not conform to best practices and often has a number of security issues within it.

In recent years things like PHP and Rails have taught us that development speed is more important than we thought it was. On top of the obvious business value of delivering functions faster, there’s the Agile/XP view that you really don’t understand a feature till you’ve built it, so the faster you can build them the faster you understand them.

I couldn't agree more. I think the debate of which language is better as Tim rightly points out, is a red herring. The answer depends upon too many variables, and I really don't think there is a right or wrong answer. The only wrong thing to do is write crappy code that you later have to completely rewrite and re-architecture. But even that is inevitable in a way.

But I agree - if there is one thing I have learned in two years is the importance shipping. If you can whip together an app in PHP in half the time you can in Java, then that should, no - it must heavily influence your decision.

On Perl

I am sad that Tim didn't profile Perl, but then again he didn't profile .NET or Python either. For me, it is a toss up between PHP and Perl every time. What keeps me in PHP at all is inertia. I have a lot of personal libraries I have written in PHP that make me more productive there. But I am aching to make the switch to 100% Perl. Why? Because Six Apart has shown me just how scalable a language it is. With Catalyst, Data::ObjectDriver, Perlbal and memcached (not all of which are written in Perl BTW) it is actually not difficult to write some of the most scalable applications on the Internet.

Dev Tools

I would argue that all you really need to work on Perl is emacs or vi. But to be fair and consistent with Tim's appraisal, I think it is important to consider the lack of really well integrated developer tools for Perl. Granted, there is Active State, but that is for Windows only and thus doesn't score a lot of points with me.

What Perl has going for it is probably one of the largest repositories of open source libraries for any programming language. And these are perhaps the most valuable tools at a developer's disposal because it allows them to build on the shoulders of giants as opposed to re-inventing the wheel over and over.

Maintainability

This is both Perl's strength and weakness. Perl's has a lot of the same challenges as PHP in regards to the accessibility of the language. But it also has the opposite problem that there are a lot of ubersmart people out there writing Perl code, and their code is often quite obscure to say the least. A perfect example is SOAP::Lite. I dare anyone to try and make heads or tails of that code. Granted, Paul is a genius, but every time I have to get into that code I feel like I am unraveling some long unsolved mathematical proof. It hurts.

But there are also coders out there that write incredibly solid code. But in the end, this complaint is true about every language, that there exists a spectrum of good and bad code, and that maintainability is not a function of the language, but a function of the developer at hand.