Good Thing Perl is Dead

PerlPilot comments that the "Perl is dead" meme annoys him. Personally, considering the apparent exponential growth in Perl-related Advent calendars this year, I think it's a good thing Perl is dead. If this is dead, a living Perl community would probably overload the Internet with Advent calendar traffic...

Silent Majority?

NPEREZ asks, "Who are these people that have a vested interested in Perl and yet do not participate?" Well, I guess until very recently I was one of them.

The core of my professional work is a set of C++ libraries. But there are 11,000 lines of Perl 5 code split across about 30 programs which are essential components supporting those libraries. Most of it is generating things, including 95,000 lines of C++ code and hundreds of makefiles, VC++ projects, etc. The Perl 5 I use is either the vendor-supplied Perl (on my Linux boxen and my MacBook) or ActiveState on Windows; my development environment requires that most of that 11,000 lines runs on every platform I use.

In this context, Perl 5 has just plain worked for me for the last decade. With a fresh Linux install it usually takes me about five minutes to get the modules I use off of CPAN and than I'm up and running. I can't recall ever having an issue with using a different version of Perl for this; it just has always worked, quickly and easily.

Given that, why would I have "participated" in steering Perl 5? I'm a busy guy, and Perl 5 has been steered perfectly for my purposes without my contribution. It took Perl 6 to draw me into the community. Now that I'm following a number of Perl blogs (thank you Iron Man), I'm taking an interest in Perl 5 development as well, because I'm excited about the newer modules I am learning about.

So I come to this issue from both sides. On the one hand, I'm very excited about new developments in Perl (both Perl 5 and Perl 6); I'm correspondingly disappointed that 5.10 has not been widely adopted, because that slows my own use of it. (Though after seemingly good results compiling a "personal" 5.10 on one of my Linux boxen, I may try switching to this approach, leaving the vendor Perl for the system to use and upgrading the version I use personally.)

On the other hand, I'd be pretty put out if someone gratuitously broke all my scripts. (The proposed idea of making "use strict" default would do it nicely, breaking all but the most recent.) I guess if the breakage could be controlled by a command line switch it would just be a minor nuisance. Otherwise the cost would likely be somewhere between days of work and simply refusing to ever update Perl 5 again.

Having just taken my first steps into the community, I don't feel like the me of six months ago somehow deserved to be screwed over just because I wasn't really part of the community then. From my perspective, the Perl community did a fantastic job of steering the language through 5.005, 5.6, and 5.8; to the extent there has been a bit of a fumble with 5.10, it seems to be the lack of updates more than the changes to the language. I'd like to see that great work continue along similar lines.

CPAN Good, Bad, and Ugly

Watching this awesome video Introduction to Catalyst, I was inspired to try it myself.

And that's when the trouble started. It's now three hours later, and I'm still trying to get Catalyst down from CPAN. And I have no confidence I will have a properly working version when it finally does finish installing.

My first attempt to get Catalyst::Runtime and Catalyst::Devel was on my Linux server's default 5.8.x Perl. It ran for maybe fifteen minutes, and then complained that there was something wrong with my distribution's Perl, and I should complain to the distribution packagers.

You know, that might seem like a great way to bring about long term change, but it doesn't seem like the most productive use of my time this morning. So I decided what the heck, let's install 5.10 just to my personal account -- the perfect way to experiment with it without risking blowing up my nice, happy server. (Besides, I've wanted access to 5.10 ever since I started reading the various Perl blogs. Too many goodies to ignore.)

Now this is another positive point -- 5.10 installation was perfectly smooth, even to a non-standard directory. Sweet!

Installing Catalyst took a long time, and came up with the following error:

# You are using perl 5.10.0 with the "Unknown error" bug. This can make #
# developing Catalyst applications much more painful, as it will come   #
# up with no details every time you have a syntax error in a Controller.#
#                                                                       #
# For more information see:                                             #
#                                                                       #
#  * http://rt.perl.org/rt3/Public/Bug/Display.html?id=49472            #
#                                                                       #
# It is highly recommended that you use a different version of perl or  #
# compile a patched version for Catalyst development.                   #

So the link there gives the number of the commit to the Perl source that fixes the bug. But it doesn't provide any obvious way of easily getting that patch. And Perl is in git now, right? I don't see any obvious way of associating that number to a git commit to extract the patch.

So now it's the next day from when I did all that. I have Catalyst installed, and it performed the basic cool step in that tutorial admirably. But I've also got this lingering unfixed bug hanging over my head, too.

And that's the mixed bag of Perl at the moment. On the one hand we have these cool things like Catalyst and Perl 5.10, and that great screencast promoting Catalyst. And on the other hand we have this funky cruft that turns what could be pure awesome into something messy and a bit embarrassing.

I don't have any idea who to blame; I suspect there is a little bit of blame spread out over a large range of not terribly guilty parties. (Including myself -- I'm sure given time I could track down how to get the patch, and put that answer here and/or patch Catalyst to put the answer there.)

But that's my experience with it. Hopefully things will go more smoothly now that Catalyst is installed...

More respectable

Here's a somewhat more respectable version of the "change files with backup" script. It uses File::Copy instead of the unportable system call in the old version, actually checks the copy call for success, and has use strict in place, too. Still not rocket science, but at least it's a bit less dodgy and more portable.



I'm considering replacing the first loop with a map, and maybe playing around a bit more with it. But first I need to tackle some C++ for work.

P.S. Two other things worth pointing out. First, this is exactly the sort of small problem Perl excels at tackling -- quick scripts that make a hard job simple. (That's not to say Perl can't tackle big projects, too!) And second, with the proper switches one can more or less duplicate this program's actions straight from the command line.

P.P.S. The file has been updated to incorporate the map idea I had, and autarch's three-arg open suggestion from the comments. Plus I cleaned up the regular expression I used to get the file extension (in retrospect, the old one was dire) and switched from || to or throughout.

May try perlcritic next.

Automagically Generating a Guide

fREW suggests some clever automatic ways to generate a guide to CPAN. Certainly if it can be done well, that is preferable to the inevitable bickering that would result from a non-objective guide!

I did have one additional notion that might help, thought I can't decide if it is crazy or not. What about some sort of opt-in anonymous module usage monitoring, ala Last.fm's scrobbling? It could help figure out which modules are in common use -- imagine doing a CPAN search sorted by usage. It could be another handy stat feeding into an automatically generated guide. It would also allow easy searches for orphaned modules that are in heavy use.

Obviously there are privacy objections, potential speed issues, worries about gaming the system, etc...

Guide to CPAN Needed

I'm all in favor of chromatic's suggestion to dump most of the core Perl modules. But I think he left out what might be the most important (and most controversial?) part of such a plan: providing a proper guide to CPAN.

In a previous post I complained about the difficulty of figuring out what MP3 tagging module to use. CPAN is great at providing alternatives, but not terribly good at providing a way to evaluate the pros and cons of those alternatives.

Now, with something like MP3 tagging that is just an inconvenience. But if it happened to core modules, it would be a disaster for Perl. The best thing about the core modules is you know they are a standard. If you want to do, say, standard file handling, you us IO::File, simply because it is there. But if it's not there, and you're a beginning searching CPAN, you'll be confronted with dozens of modules that sound like they might do the right thing. It's an utter nightmare for the poor beginner who just wants to get his twenty line script running.

It seems to me the answer is a guide to CPAN, something that points out what you should probably use and what you should avoid at all costs. Maybe it should be a web page, or a wiki, or just a standard module package that everyone should install. But something is needed, and it will have to be opinionated to be useful.

PS It is especially needed because you've got to think people will start re-evaluating those basic modules in light of the past ten years' changes to Perl (and the even greater ones coming chromatic envisions). Moose::IO::File anyone?

Perl to the Rescue

So here's a simple example of the sort of small Perl script I routinely cobble together for work. In this case I needed to run a quick external program repeatedly on a series of files and extract the parameters used inside. The files were named with whether or not they were correct, and this code uses that to build a table which sorts the files and summarizes the parameters.



There are a few ways this script is atypical for me. The brainwashing has worked -- for the first time I can remember, I actually started a script with use strict. I don't think it saved me this time, but it was simple enough to obey its strictures.

This is the first time I've used the DirHandle module. Combined with grep, it proved an elegant way to get the filenames to work on.

And actually, the use of grep to filter lists is a fairly new technique, which I think I picked up in my Perl 6 experiments.

By the way, once the full table was generated, I had the bug's cause pinned down in about twenty seconds.

Lost in the CPAN

A Foolish Manifesto has an interesting post on renaming MP3 files. It's a simple little script, the likes of which I have written several times over the years. Yet I don't recognize any of the modules he is using.

I actually noticed this the last time I tried to write one of these scripts. CPAN has a number of different MP3 tag modules, all in various states of disarray. I know I have used different modules over the years as I coded quick MP3 tag hacks, but the time between these hacks is so long that every time I feel like I'm starting fresh -- with no idea where in the maze to start.

Now fREW reveals a new one I never noticed before, Music::Tag. (Presumably it handles more than just MP3s.) I see it is at version 0.33, and hasn't had a release in over a year, which leads me to suspect it is yet another orphaned tagging module.

Is it possible for the vastness of the CPAN to actually become a disadvantage? It seems to me that if there were only one tag module instead of 5+, that one would be better supported. And it would be a lot easier for a potential user to figure out what to use.