January 2009 Archives

In discussions on PerlMonks and elsewhere about Modern::Perl, the implicit question has come up. Why does Modern::Perl refuse to install on any Perl with a version less than 5.10?

First, I offer two caveats. If you're reading this, you're probably capable of deciding for yourself which modern Perl features you want to use where. You're likely a willing CPAN user, if not a CPAN contributor. You almost certainly can explain what the strict and warnings pragmas do, and why you don't need to use diagnostics (even if you recommend that novice users do). I realize that not every reader fits that profile, but it's easy to imagine that at least nine out of ten people who read this do.

Thus, to the tens of thousands of experienced and careful Perl programmers in the world, I have some good and bad news. Modern::Perl is not for you; it will do you very little good. It's for people who don't know how to get the benefits it provides in the standard a la carte fashion. It's a buffet ticket of modern Perl goodness.

Second, any other CPAN distribution which depends on Modern::Perl and doesn't explicitly mark a perl dependency on at least Perl 5.10 is in a grave state of sin and error and deserves quick bug reports filed. You can cite me as an authority on this.

Hopefully the other six and a half billion people in the world who aren't experienced Perl programmers who proudly use and reuse and create CPAN distributions didn't mind that short digression.

There are several reasons why I consider Perl 5.8.x as "legacy", at least for the purposes of Modern::Perl. Take your pick of a few.

First, 5.8.9 is the last substantive release in the Perl 5.8.x series. It's reached the end of its lifetime. There will be no bugfixes, except perhaps for security errors. That codebase has no future.

Second, Perl 5.10.1 is on the way. I realize that the CPAN calls Perl 5.10 a "testing" release, but that's more a nomenclature problem than anything else. Perl 5 has the largest regression test suite of any modern dynamic language I've looked at -- especially when you consider that the comprehensive test suites of a good portion of the CPAN run regularly against bleadperl.

Third, Perl 5.10 fixes an amazing number of bugs and misfeatures, especially regular expression engine reentrancy problems and closure bindings. Yes, generally only advanced code exposes these problems, but they were very difficult to identify and debug.

Fourth, Perl 5.10 adds a handful of very convenient features which address common error conditions. For example, the defined-or construct is an improvement over the long-lived true-or construct used to assign default values to a variable. The problem with ||= is that it overwrites any value which resolves to false in a boolean context. That seems okay, but there's a semi-predicate problem if 0 or an empty string are legitimate values.

Another lovely feature is being able to lexicalize the universal pronoun $_. Certain looping constructs localize it. Others don't. This is often a source of subtle bugs.

Fifth, Perl 5.10 backports several wonderful features from Perl 6. The given/when construct simplifies code immensely. So do named captures in regular expressions -- and they improve readability too.

As silly as it sounds, I use say all the time. All it does is append a newline to the final string printed, but it's incredibly useful.

Sixth, Perl 5.10 improves some warnings. In particular, I'd upgrade to 5.10 for only one warning. Previous versions of Perl warned when you interpolate or concatenate a variable containing the undefined value. That's handy, but 5.10 goes further by telling you which variable contains the undefined value.

That list is not exhaustive -- I like some of the memory usage improvements too, but regular users are less likely to see those.

Maybe you don't need any of these features. Maybe you're perfectly happy with Perl as it existed in version 5.005_3 (though how can you not love lexical filehandles?). That's fine.

Note that almost none of these features are available in Perl 5.8.x (though you can get your own say(), and there's a patch available to add defined-or if you want to compile your own Perl). I can't imagine not being able to use these features, and I don't want to consider how to teach Perl to novices without some of them.

Novice programmers often seem to think that their biggest problem is learning the syntax of the language. Throw in the standard libraries, if you like. They're wrong, but that's okay -- they're novices. Their biggest problem is learning how to manage complexity. I've seen far too few tutorials teach this from the start. I believe that Perl 5 offers several excellent ways to manage complexity, and a handful of awful ways to allow complexity to spiral out of control. I also believe that a well-taught student will develop habits to prevent unnecessary complexity from creeping into a system. Let me be more concrete. Many novice programs I've read have big blocks of variable declarations at the top: my $name1 = ''; my $name2 = ''; my $address1 = ''; my $address2 = ''; ...

While that's technically a valid program (the computer doesn't care), it's probably not a well-abstracted or well-encapsulated program, and it's likely ignoring modern Perl idioms.

One of the greatest advantages of lexical scoping with enforced variable declarations -- an advantage Perl has over Ruby and Python, for example -- is that you can see the scope of a variable by looking for its declaration. If you keep your scopes small -- if you encapsulate behavior into discrete pieces -- you reduce the possibility that essential information will leak out of those scopes into surrounding code. You minimize the coupling between distinct units of behavior.

Try explaining that to a novice.

To my mind, the greatest discovery in programming is the procedure. Attaching a name to a discrete unit of behavior lets you break down a big problem into smaller problems. Lisp and Forth hackers talk about this all the time. So do functional programmers. It's true.

Try explaining that to a novice, too.

If we really believed that maintainability is the primary concern of code, and efficiency and reuse and optimization were second-order concerns, we'd explain subroutines as "a way to attach a name to a discrete unit of behavior" instead of "common code you call more than once." They're both largely true definitions, but explaining the former first confers a huge advantage in my mind. Get novices in the habit of breaking problems down into separate, named steps and perhaps they'll write better code.

If my thesis is correct -- that much of the work done on the Perl language, the Perl culture, and its ecosystem including CPAN in the past ten years has made the language easier to use and Perl programs more maintainable -- then Perl fans have a lot of work to do to overcome the weight of bad code and creaky tutorials found in the wild.

Browse PerlMonks for ten minutes, and you'll see that many petitioners receive the useful advice to use the strict and warnings pragmas in new code. Similarly, I've started all of my recent tutorials with the line use 5.010; to take advantage of say, given/when and other new syntactic features. Add to that some of the nice CPAN code which extends the language and adds even more great features....

... and the result is that a "modern Perl program" will contain at least three and probably several lines of identical boilerplate code which serves only to enable nice new features to make it easier to write powerful, effective, and maintainable Perl programs. Worse yet, many of these features should be on by default.

Do you really want to tell people that they should use say instead of print ... "\n" because the former is shorter and more concise and more convenient if you have to explain that they have to use the feature pragma to enable it explicitly?

I wrote a proof-of-concept module called Modern::Perl to solve this problem. It has five lines of code. Add use Modern::Perl; to your program and it will automatically enable the strict and warnings pragmas, and will make available all of the features of Perl 5.10.

There's still more than one way to do it, but isn't that easier than telling people to copy and paste long lists of modules to enable great features that should be available by default? Surely modern Perl should minimize copying and pasting and should remove artificial barriers between novices and experts.

Perl 5 -- the current version of Perl -- is fourteen years old now. It's had several major revisions in that time. (See Perl History for more details.) These major revisions add new features, fix old bugs, and generally improve the language. All of these changes come from real-world users who use the language themselves.

The current stable major version of Perl is Perl 5.10, released in December 2007. This release includes several features backported from Perl 6, the next stage in evolution of Perl.

Perl's a popular language. It's been around for 21 years, and it was the language of server-side programming back in the day. It's still popular. There are hundreds of books and thousands of tutorials available all over the Internet. You can learn Perl with little more than a text editor and a web browser, if you so desire.

Remember, however, the Internet rarely forgets. A Perl tutorial which represented the best version of Perl from 1991 may still be around -- and thanks to search engines, it may be the most highly recommended tutorial anywhere. Eighteen years later, Perl's moved on. We've learned a lot since then.

The best way to write Perl programs in 1991 or 2001 or 2004 isn't necessarily the best way to write Perl programs in 2009. It's time to discuss and document and disseminate all of the wisdom of the greater Perl community. It's time to talk about modern Perl.