At Oversee, we use a lot of Perl.  There are many web developers who think that Perl is obsolete.  The current “cool” languages for server-side web development seem to be Ruby, Python, or even Javascript.  The scornful developers base this opinion on the undeniable fact that Perl’s been around a long time, and there’s a lot of really crappy unreadable old Perl code floating around the Web.  What those critics often don’t realize is that Perl has been evolving quite a bit over the last few years.  This evolution is taking place on 3 fronts: language, libraries, and usage.

The language itself is changing, and new major versions of Perl are being released more frequently than in the past.  Perl 5.8 was the only major release for 5 years; since then, Perl development has moved to a roughly annual schedule of major releases, and there’s been a lot of conversations about just how much backwards compatibility these new versions need.  Perl 5.10 is bundled with most newer Linux distros, Perl 5.12 was released last spring, and Perl 5.14 is coming next spring.

Perl libraries are able to change faster than the core language, because new, incompatible libraries can be created alongside old libraries.  Because of Perl’s “There’s More Than One Way To Do It” philosophy, it’s possible to create libraries that provide major changes in the language, while still running on the same underlying core interpreter.  The most substantial example of this is Moose, a “post-modern object system” for Perl.  Moose takes ideas from Perl 6, Smalltalk, CLOS, Java, Ruby, and other more obscure object-oriented languages, and combines them into a very flexible and succinct way of creating and using objects in Perl.  In a sense, Moose creates a new OO dialect (related to both Perl 5 and Perl 6) on top of Perl 5.

Perhaps the biggest change in Perl is not what the language or the libraries provide, but what sophisticated developers are taking from it.  Starting with the publication of Damien Conway’s “Perl Best Practices” in 2005, there’s been a growing recognition that “There’s More Than One Way To Do It, But Some Ways Are Better And Some Are Worse”.  Many of Conway’s recommendations are still widely accepted, and there’s now even a tool (perlcritic) to automatically check Perl source for compliance.  However, some of his suggestions are now seen as outdated; in particular, the OO approaches he recommends have been obsoleted by Moose.  More recently, several prominent Perl authors have written about the latest consensus on how best to code in Perl. The 2nd edition of “Effective Perl Programming” by Hall, McAdams and foy came out last spring, and Chromatic’s “Modern Perl” was just released last week.

Many of the usage changes are simply a matter of encouraging programmers to more consistently use features that have been available for a while.  For example, in a recent blog post a Perl programmer talks about getting his colleagues to adopt the 3-argument form of the open() function and lexically-scoped filehandles (instead of global filehandles), both features introduced in Perl 5.6.0 in 2000.  The trouble is, there are lots of Perl examples which have been copied from older Perl examples, which might do things in ways that are more error-prone than necessary.

To summarize, Perl has changed as much as any other part of the world in the last 10 years.  If you rejected Perl based on old stereotypes, it might be time to take another look.  If you know and love Perl, it still might be time to go back and learn some new ways of using it.