Recent discussions on this site and at OSCON concern the apparent waning of mod_perl popularity. Some may lay the blame the for mod_perl’s wilting at the door of the crappy tech market that has dominate these past four years. Others may cite the confusion caused by Apache’s painful and prolonged switch from the 1.3 code base to the 2.x one. Inevitably someone will throw philosophic tomatoes at languages like java or python for stealing Perl mindshare. To this witch’s brew of finger pointing, I’d like to add this observation:
mod_perl is dying because it solves the wrong problem.
If my Perl compadres aren’t sent into paroxyms of rage, consider this line of reasoning. Perl became popular in the nineties as a tool to build web applications via the CGI. mod_perl and fastcgi appeared to turn down the suck knob on the poor performance of those early CGI apps (jeez, they were running on PIII machines; what sort of performance did we expected?) Whereas the fastcgi apache module was meant to make perl CGI “run faster”, mod_perl embedded the perl interpreter into apache and created the Perl API to the request cycle of the web server that we all know and love. And as sort of an afterthought, mod_perl also provided a mostly CGI compatible module called Apache::Registry for those that wanted to port existing CGI stuff. But the expectation from the mod_perl camp was that everyone would get into writing apache modules using mod_perl.
This just ain’t so.
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 lanuages. After all, most of us are hired to build a system to solve a business problem. And since writing software for a specific client platform is teh suck, HTTP/CGI is a better platform to program to. A quick look at freshmeat’s projects by language reveals this:
- Perl: 3146
- PHP: 2682
- Python: 1566
- Java: 3301
- Lisp: 44 (included for entertainment purposes only)
Since freshmeat doesn’t discriminate between web apps and non web apps, a little fudging is needed to get at my point. While many of the Perl, Python and Java apps listed freshmeat are web apps, almost all the PHP projects are web apps (there are some weirdos out there using CLI PHP). People like using PHP for web stuff and now I know why.
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.
Moreover, users are more likely to try out those PHP apps with their
sexy screenshots than go through the hassle of installing a mod_perl app.
PHP, until recently, had no illusions about what sort of programs its users intented to write. It’s syntax, “library management” and poor namespace control are all a product of it’s problem domain. PHP are easy to write and painless to dispose of. PHP, along with thrice-damned VBScript/ASP, are as the best tools I’ve seen for rapid web prototyping.
mod_perl doesn’t nothing directly to aid web app development. PHP, with its shotgun spray of built-in libraries to do everything from PDF generation to cybercash functions, 0wnz mod_perl.
If you’ve never installed a PHP app, do. It usually involves downloading
an archive, unpacking it in a PHP-aware document root and pointing your browser
to the appropriate URL. A web page will walk you through the rest of the
setup. This procedure appears to be the rule, not the exception. In the past
year, I’ve installed the following PHP apps: phpBBS, sugarCRM, Jinzora (mp3 streamer), Agatha ([poorly written] mp3 streamer) and SITR knowledge base.
Have you installed any mod_perl apps lately? RT (requires Mason, DBI)?
Slash (requires Template Toolkit, DBI)? Wiki and Movable Type are two
perl apps I can name that are most PHP-like in their installation. I’m not
denigrating Perl, mod_perl or the Perl apps I’ve named. I’m pointing out that
the installation of these apps is a barrier to entry for many people. Perl
may be share some blame in this too. Perl’s core set of bundled
(or “built-in”) modules is small compared to PHP, so apps that actually
do something besides parsing log files require a trip to CPAN. Oh, you’ll
probably need to configure apache for mod_perl. And a Directory section for
your mod_perl app. So, you’ll need to restart apache.
ugh.
mod_perl isn’t getting web developers because it isn’t a web application framework. PHP is.
A postscript
In a vain attempt to forestall the stupid comments, here’s a list of things I’m not saying:
- Perl sucks
- PHP rulz
- mod_perl is garbage
- PHP is delightful
- PHP’s design choices are perfect
- Perl should be exactly like PHP
- Don’t code Perl
- Don’t write Perl web apps
- Only write PHP web apps
- You can’t write good web apps for mod_perl
What I am saying is use the right tool for the job. For web apps, PHP is frequently the better tool. mod_perl isn’t tool, but a platform.
Now count to 10 and write the smart comments below.