Progressing vs. leapfrogging

| 4 Comments

In this blog post, "Ugly Old Perl", the author discusses how he(?) is still finding old Perl code like this:

open(FH, "<<$runpath/log/output.log ")
    || die "Can't write output.log!"

instead of the newer safer

open( my $fh, '<<', "$runpath/log/output.log" )
    || die "Can't write output.log!"

He discusses how he's tried to introduce his co-workers to three-arg open calls, and they have no idea that such a thing exists. Perl 5 has become such a success, so ubiquitous, that people don't realize there have been improvements since they first learned it.

I'm sure these people don't know any of the changes made to Perl regexes, too. They might still be using study as part of the belief that it magically makes regexes match faster.

These are the users that will never use attributes, or Moose, or much of anything discussed in Modern Perl.

I'm OK with that.

These are the users who are going to stick with the Perl they know until they leapfrog to something else. That something else might be Ruby, or it might be Perl 6, but I know that they're never going to make a straight progression.

If you're reading this blog, chances are you're a progresser. You follow each Perl release. You are interested in the incremental changes. You want to know about named captures in regexes and you find ways to use them in your existing code.

But most of the users of Perl aren't. They're using Perl as a tool to get stuff done, and it's not a hobby. There's nothing wrong with that. They won't change their way of seeing Perl until there's something to leapfrog over. All we can do is make Perl 5.12 or Perl 6 a fantastic target to leap to, something to entice them to make the leap.

(Aside: He also brings up the idea often trotted out that Perl 6 be named something other than Perl. It won't happen, so there's no point in discussing it.)

4 Comments

I'm not computer scientist. I started out with C++ and some scripting languages for various applications. Found Perl and have not looked back. To continuously improve your skills, nay, artistry you need to keep up to date with all the changes and new features. A hammer is a good tool, but if you don't know that there are such things as roofing hammers, you're not going to be proficient at installing roofs. That analogy goes on for a long time. You may be a good driver but sticking with your '51 Ford Fairlane may not be the safest choice you can make.

Agreed; Perl 6 should be Perl 6. You won't buy a new Ford Fairlane, but you will buy a new Ford of some name (well, if you like Fords - but you get the point). There's a reason they didn't call it Redmond GUI Longhorn.

In my company we're using CentOS 5 which still includes Perl 5.8.8. So don't have a real reason to really learn all the new features (such as the named captures) because I will never use them. Why are things so slow?

One reason I find that many people stick with older Perl versions is the "lowest common denominator" reason. In many sites, the software has to be supported by a vendor...and these vendor distributions are woefully behind the times. So there is more dis-incentive to employ features specific to Perl 5.12 or Perl 6 since you won't be able to use it the production environment anyway.

..and then there are the CPAN modules. Don't get me wrong, I couldn't code without them...they are great....but, the dependency chain can be another dis-incentive to modernize your Perl. I can't count the amount of times I have wanted to install "just one" CPAN module, and along comes this endless dependency chain of other modules. This is less than fun when they firewall off direct access to CPAN. For example, one doesn't just install the DBIx-Class module as standalone unit. Here I think the real issue is packaging related groups of modules...and Perl doesn't shine in this area.

So for many Perl programmer's, we dream in Perl 6 but reality is several revisions behind.

If you use your vendor perl, you can install CPAN modules as vendor packages.

As for packaging set of modules with program, you can use Shipwright.

Leave a comment

Job hunting for programmers


Land the Tech Job You Love, Andy Lester's guide to job hunting for programmers and other technical professionals, is available in PDF, ePub and .mobi formats, all DRM-free, as well as good old-fashioned paper.