I’ve mentioned previously that ApacheCon could be rebranded as JavaCon and few people would notice (well, maybe JavaWebCon). While only 33 of the 68 sessions were specifically about Apache projects written in Java, the dominant technology in use among the members of the Apache Software Foundation is undoubtedly Java. In fact, in a session on extending SpamAssassin with plugins—a project written in Perl—the presenter jokingly asked if anyone was rewriting SpamAssassin in Java. Don’t get me wrong, a lot of these Java projects are amazing. I don’t know how Java gained such prevalence in the ASF, but it has.
Interestingly enough, the most popular session at ApacheCon was not about Java, but about Ruby on Rails. It was standing room only. This seems to go along with the hype this project has gained over the last several months. In the hall outside the presentation room, one developer, obviously biased towards Java, snidely commented that Ruby on Rails was a fascinating toy and something to be expected from a scripting language, but would never be as robust as the type-safe Java.
For all of its hype, Ruby on Rails still doesn’t hold a candle to the popularity of PHP as a scripting language for the Web. In fact, I would guess that the population of PHP coders at ApacheCon was second only to the population of Java coders.
I am not anti-Java or anti-Ruby or anti-PHP (well, maybe slightly anti-PHP, but that’s another rant). If people want to code Web applications or whatever else with these languages, more power to them. However, I am a Perl monger. I’ve been a Perl monger since I first discovered Perl 4 in 1995 and I’m likely to be a Perl monger for a very long while yet. So where is Perl? Where are all the Perl mongers? Jumping ship or hiding in caves, I imagine. For good reason, too.
To put things in perspective, a short review of history is required. Apache HTTPD 2.0 was released from beta on 6 April 2002. Following this, mod_perl 2.0 was released from beta on 19 May 2005. That’s right, over three years later! To make matters worse, in order to ship the latest and greatest version of Apache HTTPD, various revisions of mod_perl 1.99 were included in Red Hat Linux 8 through Fedora Core 3 and is even still being distributed with Red Hat Enterprise Linux 4.2. Oh, but it gets worse still. The these revisions of mod_perl all come from before the great API shakeup in the final release candidate of mod_perl 2.0. To maintain compatibility, RHEL can not even ship the latest stable version of mod_perl 2.0. Now, would you use mod_perl?
What happened in these three years? Well, a lot happened. For other technologies.
Web Application Framework is now all the rage. To this end, PHP 5 was released and Ruby on Rails became the Next Big Thing (also, even more Java projects were under the ASF umbrella). Meanwhile, developers using mod_perl weren’t doing anything they hadn’t already done with Apache HTTPD 1.3. Prominent mod_perl developers stated (and still state today) that they have not moved to Apache HTTPD 2.0 because there are no compelling reasons for them to do so. Mason, my template engine of choice, only recently added support for mod_perl 2.0. Bricolage, a wonderful CMS that I’d like to use, still only runs under Apache HTTPD 1.3 because mod_perl 2.0 took so long to release. Sure, I could just build Apache HTTPD 1.3 from source, but why? Apache HTTPD 2.0 as well as mod_perl 2.0 are already included in Fedora Core 4, and why should I install an older and inferior version of something when I already have the newer, better version?
There are two things that frustrate me even more than the delay in shipping mod_perl 2.0. First, the API change in release 1.999_22 (the fifth release candidate!) was awful. Admittedly, it was for the best and it was a simple task for me to update my code, which had not yet been released. However, to do this so late in the development cycle only hindered acceptance and, as I have already mentioned, have kept distributions such as RHEL from upgrading to the latest version. Second, when asked how much longer before a mod_perl 2.0 release, the lead developers merely say it would be done when it was done and if people would use it then it would be finished faster. Okay, I can see why they would say that, and the developer in me even agrees with them; however, this does not make for good relations with the people using the software. It becomes a cyclic argument: no one uses it because it’s not done, but it’s not done because no one uses it.
Now that mod_perl 2.0 has finally been released, there have been recent attempts to catch PHP and Ruby. Catalyst is one such attempt. Thus far, I see it gaining hype, but only in the Perl community. As yet, I don’t see the cross-spectrum popularity that PHP or Ruby on Rails enjoy. It still feels that many Perl developers are either using plain CGI or rolling their own frameworks, just like we did in the pre-2.0 days. I imagine much of this is due to one of Perl’s guiding philosophies: There Is More Than One Way To Do It. While this approach is one of the reasons I came to Perl in the first place, it tends to litter CPAN with various ways of doing something that isn’t quite what is needed.
In those three years before mod_perl 2.0 was finally released, I grew discouraged with Perl. I started to feel like I wasn’t using a “real” programming language like those guys using Java or .NET. In August, Damian Conway gave his talk on Life, the Universe and Everything to my local Perl Mongers group. Suddenly Perl was fun again. I remembered why I was a Perl monger.
So, with all of this, what is a poor Perl Web developer to do?
Don’t get discouraged. Keep on coding. Get involved!
If enough people jump on the Catalyst bandwagon, maybe Catalyst will be the Next Big Thing at ApacheCon 2006.
Meanwhile, I have some Perl hacking to do.