On "Serious" Perl

I wrote my first Perl module last night.

This, coming from a former sysadmin, is Big News. It's Big News because there are three ways to perceive Perl, and each way represents a major evolution in how one understands the language.

The first way to understand Perl is as a scripting language. This is where most everyone gets their feet wet in Perl because they've been led to believe that there is something Perl can do quickly that they will otherwise have to do by hand. Perl is great for taking a big log file and return the first, third, fourth, and ninth fields of each line. There are honest-to-God reasons why you might need to do this, so Perl is there for you:

#!/usr/bin/env perl

while (<STDIN>) {
 my @arr = split(" ", $_);
 printf("%s %s %s %s\n", $arr[0], $arr[2], $arr[3], $arr[8]);
}

It's not elegant, but hey, it will get the job done. With minor tweaks you can do just about anything in a "while <STDIN>" loop. This is where Perl becomes the Swiss Army Knife of system administrators because of its raw utility. Any sysadmin worth his salt is going to have a library of Perl scripts scattered hither and yon doing a myriad little tasks that would otherwise require an expensive software package or manual intervention. Sysadmins don't like doing things by hand, so every Perl script they can run to do a job is that much more time they can spend on Sudoku at their desk instead of down in the server room fighting daemons.

The second way to understand Perl is as a real programming language, with objects and methods and constructors and all those other Comp Sci abstractions that make your head spin. Here is where Perl stops being a dinky .PL file that you run from a crontab and becomes some sort of sophisticated mesh of subroutines and hashes. Writing Perl code is not the same thing as hacking up a Perl script, and it requires reading parts of the Perl documentation that would make a sysadmin scream and run for his shell scripting books. Perl code is decidedly non-linear: the script you wrote yesterday starts at the top and goes to the bottom and it's all in one nice, happy file. The module you write today could be anywhere in @INC, which is itself a horrendous beastie of other modules you may or may not have to include, and it can have its constructor just about anywhere. Perl coding is the art of choosing the right interfaces to a data structure that you could oh-so-easily just stick into a .PL and be done with, but if you were willing to just slap everything into a .PL, you wouldn't have evolved to this stage of Perl mastery.

My first Perl class is hardly worth noting and accomplishes nothing worthwhile:

$ cat ./MyTest.pm                                                     
package MyTest;

sub new {
        my ($class, $name) = @_;
        my $self = { "name" => $name };
        bless($self, $class);
        return $self;
}

1;

To be honest, I haven't quite figured out what this class does, or where the class begins or ends, or what bless()'ing accomplishes other than the obvious. I've read perlobj and Writing Serious Perl, and bit by bit it's starting to sink in. It seems pretty clear to me that Perl wasn't really designed to "do" object-oriented programming, but in today's world generating as many modules as currently exist in CPAN without it would be a nightmare. I suppose that if I just wanted easy objects, I'd stick with Python, but Python is not Perl, and there are several reasons to stay with Perl even when reaching that stage where you need to stop scripting with it and start programming with it. A Perl program can be very powerful, and yet very hard to debug. It's a social event, really: you've decided that your idea is too large to fit into a script and is finally ready to be used and abused by other people who are not willing to do much more than run "install Your::Module" and try "Your::Module->new()" to integrate it with their projects.

The second phase of Perl is an important one, simply because it means you've reached the point where you are ready to understand how the Perl community convinces their code to sanely interact with each other. Most sysadmins don't even think about that kind of thing.