Tuesday September 14, 2004

I keep hearing from mercenary recruiters from Amazon about technology jobs requiring mod_perl and HTML::Mason knowledge (I tell 'em "No Thanks But Say Hi To Jon For Me" -- I doubt they ever do) . Hearing that one of the topics of conversation at this year's OSCON was the demise of mod_perl came as quite a surprise.

According to the Journal of jjohn, mod_perl's problem is that it's a CGI enabler (psychobabblisticly: it allows web developers to indulge in Bad Things). jjohn sez...

Now, it's not that mod_perl suck (it doesn't) or that it's not useful in some situations (it is), is just that MOST PEOPLE ARE SIMPLY DOING CGI CRAP. That's right, stupid CGI + HTML is a kind of universal Microsoft Fundation Class that works for programmers of all languages.

PHP is a terrible language. Perl has long suffered with the albatross of its highly syncretic origin and it's "organic design". However, PHP is a lot worse. It's a kitchen-sink language where crazy things like mysql routines and GD libraries are part of the core language. While objects were around in PHP 4, few PHP systems use OO style. To put a fine point on it, most of the PHP apps I've looked at are poorly written and a bear to debug.

And yet, PHP is frequently a better choice than Perl for web apps.

Besides the close association to the CGI aspersion, the big problem that Perl and mod_perl suffer from is that it's too damn easy to build templating web component frameworks. HTML::Mason, HTML::Embperl, Template Toolkit, HTML::Template, Apache::ASP and so on and so forth ("but wait! there's more..."). How many goddamned many of these do we need? The overlapping similar-but-different functionality borders on Not Invented Here neuroses. And so at a certain point, TMTOWTDI is a liability. As a programming language, PHP suffers from a similar TMTOWTDI blight. For instance, for file path values, there's pathinfo but there's also dirname and basename, which are completely redundant.

So if you're going to use a language and component system that sucks (and they all do), perhaps the thing to do is to use the one that sucks the least. Despite the OO additions to PHP language for PHP 5 (notably absent: real exceptions), it's a tough case to make that PHP sucks less than mod_perl. Maybe the PEAR libraries and the Smarty component system make it a little more usable. Maybe. Perhaps mod_perl's maturity and Perl's general usefulness inside and outside of the web environment is an enduring asset. But I'm not convinced one way or the other. Screw it! Use mono and ASP.Net!

OK, probably not.

In the meantime, I'm looking into combining Maypole and Mason to get a framework together to support the applications that MVC is appropriate for.