Milestones in the Perl Renaissance


If the thesis behind this web site is correct, something called Modern Perl or Enlightened Perl exists. It's definable. A well-socialized member of the Perl community can look at a piece of code and say "That's modern!" or "That's not modern!" Code has an aroma; we speak of code smells as antipatterns. Good Perl 5 code written in 2009 has identifiable characteristics which distinguish it from bad code written in 2009 or mediocre code written in 2004 or decent code written in 1999.

Many of those differences are subtle. Some come from Perl Best Practices. Some don't.

It's interesting to me to consider some of the changes in the Perl community and in Perl 5 itself which contribute to the new Perl 5 renaissance. This list is obviously subjective and perhaps incomplete in places, but I see these events as particular watersheds.

  • Perl 5.6.0, released in March 2001. The addition of lexical filehandles alone mark a huge divide between ancient Perl and modern Perl -- almost every code example I've seen in the past eight years which eschews lexical filehandles for globals (even localized globs) has other stylistic problems. It's a shibboleth, but it's a reliable one.
  • Test::Simple, first released in March 2001. Prior to this, most of the testing of CPAN modules relied on self-described black magic, autogenerated by the long-in-the-tooth h2xs utility and placed in a file called

    ######################### We start with some black magic to print on failure.
    # Change 1..1 below to 1..last_test_to_print .
    # (It may become useful if the test is moved to ./t subdirectory.)
    BEGIN { $| = 1; print "1..1\n"; }
    END {print "not ok 1\n" unless $loaded;}
    use NewModule;
    $loaded = 1;
    print "ok 1\n";
    ######################### End of black magic.

    Compare that to modern test writing with Test::More or Test::Class or Test::LectroTest.

  • Module::Build, originally released in August 2001, intended as a release for ExtUtils::MakeMaker, which must die!. Even though it took a few years for M::B to be a complete replacement for EU::MM, it's been a huge improvement over the mess that is EU::MM.
  • Test::Builder, first released in September 2001. Extracting the plan and counter and basic test reporting features from Test::Simple and Test::More into a reusable single object allowed the explosion of Test::* modules available on the CPAN now. I believe this is a primary driver of Perl's test-infected culture.
  • PAR, first released sometime before February 2003, is an impressive toolkit for bundling Perl 5 applications into a single redistributable file.
  • Perl 5.8.1, released in September 2003, represents a huge amount of work put into testing the Perl 5 core. Perl 5.8.0 had some of this work, but the number of assertions in the core test suite quadrupled sometime between 5.6.0 and 5.8.1. That number has only increased.
  • Perl 6 Apocalypse 12, released in April 2004 (superseded by Perl 6 synopsis 12 and Perl 6 Synopsis 14), which described a very Perlish but very powerful, declarative, powerful, overridable, and even shiny and new object system for Perl 6. Of particular interest is Perl Roles.
  • CPANTS, released sometime before July 2004. This service provides automatic analysis of all distributions uploaded to the CPAN for quality of packaging and other metrics which often indicate high quality of code.
  • The book Perl Best Practices, released in July 2005. Damian didn't get everything right -- in particular, inside-out objects had a short lifespan -- but the resulting discussion of coding standards and good style helped catalyze good design practices on many projects.
  • PPI 1.0, released in July 2005, forms the basis of important tools to analyze Perl 5 code statically. This is important for....
  • Perl::Critic, initially released in August 2005. This tool continues to grow more indispensible; it's a great (and customizable) way to analyze your code for good style.
  • CPAN Testers, website launched in 2006. The project itself dates back to 1999, but several toolchain and testing culture improvements culminated into the amazing automated system that CPAN Testers is today.
  • Moose, originally released in March 2006. Moose may be the most important project in Perl 5 in the past five years. It takes some inspiration from Perl 6 objects, of course, but also Smalltalk, CLOS, and other well-explored and well-understood systems and produces a very powerful, very usable, and very perlish system.
  • Strawberry Perl, released as an alpha in July 2006. This distribution of Perl 5 includes software and configuration so that Windows Perl users can take full advantage of the CPAN.
  • Devel::Declare, first released in September 2007. This may be the most important project in Perl 5 for the next five years. It allows language extension in Perl 5 itself without the use of source filters. I use this module as shorthand for several other important distributions and features.
  • local::lib, first released in September 2007, intended to make CPAN module installation much easier as a non-root user. (CPAN and CPANPLUS shell improvements help as well.)
  • Perl 5.10.0, released in December 2007. In particular, the feature pragma relieves some of the pressure of backwards compatibility when adding new features to the language. I'm not a fan of how it works, but I'm glad that something exists to break that logjam.
  • Padre, the Perl IDE written in Perl, first released in July 2008. (Honorable mention also goes to Kephra, which dates back at least to December 2007.)
  • The Enlightened Perl Organization, formed (I believe) in late 2008 and early 2009, intended to enhance Perl 5 and modernize the core and the community. An early glimpse at its extended core initiative is Task::Kensho.
  • Iron Man Perl Blogging Challenge, announced in April 2009, which has dramatically increased the amount of discussion in the Perl world.

I may have missed a few spots along the road; feel free to fill in any gaps you see. I've deliberately left off most of the events of the past several months. Time will let us judge their efficacy and their legacies.


What I really like about this article is how it shows the Perl community's gradual acceleration into the state we are in today - we have a mature, stable language that still has an incredible amount of future potential. Over this time, bright, ambitious programmers have created tools and frameworks that show clearly Perl's ability to remain a superb language in which to continue development, and start new projects.

Of course there is plenty of cruft, legacy code and plenty of programmers still employing outdated techniques and practices... but in every language that has been around for 10+ years I see plenty of that.

The pattern I see in the Perl Renaissance you have laid out here is the clear commitment *and* ability of Perl (both the community and the language) to be flexible, maintainable, portable, scalable and approachable even today, with a programming landscape far different than 15 years ago since the introduction of Perl 5.

Despite the clamor of Perl's critics and nay-sayers, looking at this time-line, one can see that the progress of Perl 5 has not stagnated in the least - it has clearly accelerated!

I'm sure that there will be many new, shiny languages available in the future, and I will likely learn more than a few of them... but I know I can look forward to hacking on Perl 5 for a long time, and maybe even contribute to its continued evolution in my own ways someday!

"If the thesis behind this web site is correct, something called Modern Perl or Enlightened Perl exists. It's definable. A well-socialized member of the Perl community can look at a piece of code and say "That's modern!" or "That's not modern!" Code has an aroma; we speak of code smells as antipatterns. Good Perl 5 code written in 2009 has identifiable characteristics which distinguish it from bad code written in 2009 or mediocre code written in 2004 or decent code written in 1999."

Well said. (And a great summary of Perl's milestones. Many thanks.)


I think you missed one.  Without the one you missed, I doubt we would have gotten to your first point (5.6.0).


Yes, most, if not all, of the code that went into CPAN before Perl 5.6.0 had significant issues.  It couldn't help it; the language hadn't really been improved to the point where one could write the clean code that we are writing today.

However, without that base, Perl would not have had nearly the acceptance that it had.  It probably wouldn't have survived long enough to get fixed (or for the fix to matter).  Yes, Perl might have still had some adherents holding to it for many decades without CPAN, but I think they would have been about as numerous as awk programmers.  (Not to disparage awk, but I certainly haven't encountered many awk programmers lately.  Specifically, I know one.  I also haven't seen any awk job adverts in years.)

Also, the problems with the Perl language would not have been nearly as visible to you Perl maintainers.  Yes, you all would have encountered poorly written Perl code moderately frequently, but the prevalence of such code would not have been apparent.  With such a large body of Perl code in one place, I'm certain it was more apparent that it wasn't just a few bad programmers, but instead missing features and inconsistencies within the language.  You would have seen it in your own code, but if you're at all like me, you'd have taken significantly longer to admit it was the language and not just your own communication difficulties.

Modern Perl: The Book

cover image for Modern Perl: the book

The best Perl Programmers read Modern Perl: The Book.

sponsored by the How to Make a Smoothie guide



About this Entry

This page contains a single entry by chromatic published on July 29, 2009 2:43 PM.

Fixing a Bug in Perl 5 was the previous entry in this blog.

The "Dependencies Yay/Boo" Debate is Subtly Wrong is the next entry in this blog.

Find recent content on the main index or look in the archives to find all content.

Powered by the Perl programming language

what is programming?