Read an Excerpt
Preface
Worldwide, there are well over 200 billion lines of software that are fragmented, redundantly defined, hard to decipher, and highly inflexible… organizations run the risk of being mired down by a mountain of legacy code.—William Ulrich, Legacy Systems: Transformation Strategies
Congratulations! Let's say you just graduated with a computer science degree and now, bucking the economic trend, you've landed a job at a prestigious company with a large information technology department. You're going to be replacing Bill, a programmer who won the lottery and was not seen or heard from again, save for a postcard from Puerto Vallarta two weeks later. Your coworkers warn you not to mention the postcard to your supervisor. You sit in Bill's cubicle throwing out pieces of vendor advertising left in the center desk drawer, thinking about how you're going to apply the elegant principles and sublime paradigms that professors inculcated in you at college. Just then, your supervisor arrives and, leaning over your shoulder, taps at your keyboard, bringing up a file.
"This is the last program Bill was working on. We think it's almost finished. We're behind schedule, so see if you can get it done by Thursday at the latest."
As he leaves, you look at the program's tangle of misindented lines and cryptic variable names, searching for comments, but the only ones you can find read, "XXX-Must change" and "Kludge!-But should work." You wonder whether this is a corporate hazing ritual, but your instinct tells you otherwise.
Welcome to the real world.
In the real world, you're lucky if you get to spend all your time developing one new program after another. Much ofthe time you'll have to deal with someone else's. In the real world, programmers take over responsibility for programs written by people they might not know, like, or agree with. Even if you're fortunate enough to avoid this situation, you'll still have to maintain your own code; and one day you're going to look at something you wrote two years ago and ask, "What idiot wrote this?" Thereby arriving at more or less the same situation as the less fortunate programmers.
This book is about taking over Perl code, whether written by someone else or by yourself at a time when you were less wise about maintainability. Many problems of code inheritance are common to all languages, but I have noticed them especially in Perl.
Why does Perl tend to foster maintenance issues? The answer to this is the dark side of Perl's strength and motto: "There's More Than One Way To Do It" (enshrined in the acronym TMTOWTDI). Perl provides so many ways to do it that someone else quite possibly picked one that wasn't your way, or might have used several different ways all in the same program.
The medical metaphor for this book stems from the rather drastic nature of the work we do as maintenance programmers. Often we must perform triage, deciding what code is worth saving and what is beyond redemption. Frequently we only have time for first aid, applying a field dressing to a ruptured program. We also have a hard time explaining our bills to the client. There may not be a Hippocratic Oath for programming, but it wouldn't hurt to come up with one.
I wrote this book because I kept finding myself telling my students, "I'm going to teach you how to program Perl well, but I'd have to teach you a lot more before you could take over a program that wasn't written well, and you wouldn't appreciate taking that much time away from learning how to write good programs of your own." So I've written a book to fill that need.
Perl is to computer languages as English is to human languages: bursting with irregular verbs, consistent only when it's convenient, borrowing terms from other languages to form a great melting pot of syntax. Most computer languages are described in terms of some kind of functional niche (Pascal: teaching computer languages; FORTRAN: numeric analysis; Prolog: rule-driven expert systems; etc.). Perl's makers simply describe it as "a language for getting your job done." Perl hosts a fantastic conglomeration of syntactic devices that allow a programmer from virtually any background to find a familiar foothold for learning the language.
The full picture isn't as chaotic as this might imply: Larry Wall and others have done a brilliant job of tying together these eclectic devices into a framework that has an essential beauty. Therefore, just as the British speak of a "BBC English," while many people program Perl with, say, a LISP or C accent, there is something approaching an "accentless Perl" style that leverages the language's features to their best advantages. I will show how you can "speak Perl like a native" in order to optimize the maintainability of your programs.
It's true that you're officially allowed to program Perl in "baby talk" and Perl gurus have promised "not to laugh." (See the same preface.) But by the same token, while aviators call any landing you can walk away from a good one, what I'm doing in this book is helping you avoid having your pilot's license revoked.
Perl is like those people behind the travelers' help desk in airports; it's very good at understanding you no matter how poor your command of their language is. Because there are so many ways to write a Perl program that is not only syntactically correct (Perl makes no objection to running it) but also semantically correct (the program does what it's supposed to—at least in the situations it's been tried in), there is a wide variety of Perl programming styles that you might encounter, ranging from beautiful to what can charitably be described as incomprehensible.
The savvy among you will take that information and ask, "Where do my programs fit on that scale?" Because someone else may end up inheriting your code, and you'd prefer that they not end up sending it to authors like me as bad examples to go in books like this. See Chapter 5 for more advice on avoiding scorn.
If your experience or image of Perl is limited to short, mundane scripts, this book will appear to be overkill. I want you to know that Perl can quite easily accommodate large—as in tens of thousands of lines of code, multiple modules, and multiple programmers—projects. Projects of the size that demand rigorous requirements, documentation, and testing. If you're used to Perl programs escaping that sort of attention, I believe that is partly the result of a misperception of the role and power of Perl.
For example, if a C program is written to fulfill some requirement and turns out to be 1,000 lines long, then the common reaction is, "This must be serious … we'd better have code walkthroughs, acceptance testing, operational readiness reviews, and static code analyses. Oh, and don't forget the Help Desk training and documentation."
But if a Perl program that fulfills exactly the same requirements weighs in at 100 lines (and 10:1 is a typical compression ratio for C code to Perl), the reaction is more likely to be, "Ah, a simple utility … and in a plebeian scripting language to boot. Just plunk it in the delivery directory and get on with the next task."
When a Perl program reaches the 1,000-line mark, however, the honeymoon is probably over. Much of what I have to say addresses large programs. Chapter 3 in particular will show you how to get the respect of development teams who are used to putting everything through regression testing.
Please also see my earlier book with Ed Wright, Perl Debugged (Addison-Wesley, 2001) for more advice on good practices for developing and debugging Perl programs.Perl or perl?
When you read this book and other works about Perl, you'll see an apparent inconsistency in capitalization: sometimes it's written as "Perl", and others as "perl". There's really no inconsistency; the authors are referring to two different things. Perl is the language itself; perl is the program that runs Perl programs. There is only one Perl, but there are many perls (one or more for each type of computer).
Sometimes this distinction gets a bit blurred: For instance, most people will write, "Perl objects to mismatched parentheses" when it is arguably the program that's doing the objecting and not the language. Just don't write "PERL"; Perl isn't an acronym, it doesn't stand for anything. (Well, aside from standing for diversity of expression, freedom from artificial constraints, and the right to have fun in your work. But we'll get to those later.)Obtaining Perl
It would be remiss of me to tell you so much about Perl without telling you how to get it, although these days it's hard to avoid; you probably already have it, especially if you have any flavor of UNIX or Linux. The easiest way to find out whether you have it is to get a command prompt and type:
perl -v
and see if you get a response. If not, try:
whereis perl
which on a UNIX system or similar will look around for Perl. If that doesn't work for you either, here are brief instructions on how to download and install Perl:
- For Microsoft Windows machines, get the free ActivePerl distribution: <http://www.activeState.com/ActivePerl/download.htm>.
- For Macintosh: <http://www.cpan.org/ports/index.html#mac> (That URL is for pre-X versions of the OS; Perl comes with Mac OS X and builds fine on it, too.)
- For binary distributions for all other machines: <http://www.cpan.org/ports/>.
- For the source of perl itself: <http://www.cpan.org/src/>.
The source file you want is called stable.tar.gz. The file devel.tar.gz is for Perl developers or testers only, and the file latest.tar.gz is the same as stable.tar.gz for complex historical reasons. Anything mentioning "Ponie" will be for developers only through 2004 at least, and any perl with a three-number component version with an odd middle number is likewise a development version.
Building Perl from source on a supported UNIX architecture requires just these commands after you download and unpack the right file:
./Configuremakemake testmake install
The Configure step asks you zillions of questions, and most people won't have a clue what many of those questions are talking about; but the default answers Configure recommends are usually correct.
<www.cpan.org> is the master Comprehensive Perl Archive Network (CPAN) site, mirrored around the world. CPAN is also the official repository of contributed modules (see Section 8.1).Historical PerlYou're probably not used to seeing instructions on how to obtain an out-of-date version of Perl. But you just might have to do that under some circumstances that will be explored later in this book. (Note: The older the version of Perl, the less likely the references I am about to give will enjoy substantial longevity.) The timeline for all releases of Perl is in the perlhist documentation page. You can get all major versions starting with 5.004_05 from <ftp://ftp.cpan.org/pub/CPAN/src/5.0/>. Earlier versions of Perl 5 (with the exception of 5.004_04, which was widely used) exhibited significant bugs, memory leaks, and security holes and are harder to find. However, you can get what looks like every version of Perl ever released at <http://retroperl.cpan.org/>. Using a perl before version 5.003 is not an activity to be undertaken lightly. You will not receive bug fixes or any other support beyond a terse admonition to leave the Stone Age and upgrade to a real version. I am revealing this source only for cases in which you must use an old perl to verify operation of a legacy program that does not work on a modern perl. If you must get a perl 4 from there, the last and best version of Perl 4 is version 4.0.36.
Retroperl even includes versions 1.0, 1.010, 2.0, 2.001, 3.01. To call these of historical interest only would be an understatement. If you think you need to get one of these perls for any serious work you may be more in need of an archaeologist or a therapist. As an example of nonserious work, however, in 2002 Michael Schwern and others released an upgrade to Perl 1 (bringing it to version 1.0_15) as a birthday present to Perl and Larry Wall, to show that it could still work on modern machines. See <http://dev.perl.org/perl1/>.
Historical versions of modules are under <http://backpan.cpan.org/modules/>, but you'll have to go down the authors branch to find what you want.Who This Book Is For
If you've been working with Perl long enough to have heard terms like scalar, array, and hash, then you're in the right place. Parts of this book are aimed at early beginners and some parts require more experience to comprehend. Feel free to skip past anything that's over your head and come back to it at a later date.For Further Reference
Visit this book's Web site at <http://www.perlmedic.com>.Perl VersionsIn this book, I refer to the latest "stable" version of Perl, which is 5.8.3 as of this writing. The vast majority of what I say works unaltered on older versions of Perl 5, but not Perl 4. If you use any version of Perl older than 5.004_04, you should upgrade for reasons unconnected with features: 5.003 had issues such as security problems and memory leaks. You can find out the version number of your perl by passing it the -v flag:
% perl -vThis is perl, v5.8.3 built for i586-linuxCopyright 1987-2003, Larry Wall...
Perl won't execute a script named on the command line if the -v flag is present. A more detailed description of your perl's configuration can be obtained with the -V flag; if you use the perlbug program that comes with perl to issue a bug report, it automatically includes this information in your report.
A separate development track exists for Perl; you will know if you have one of those versions because the release number either contains an underscore followed by a number of 50 or larger or contains an odd number between two dots. Nothing is guaranteed to work in such a distribution; it's intended for testing. If you find you have one and you didn't want it, the person who downloaded your perl probably visited the wrong FTP link. This happens more often than most people would think; take a moment to check your perl if you're not sure.Perl 6
If you've spent much time in the Perl universe, you've heard about Perl 6. I won't be covering how to port programs to Perl 6 for a very logical reason: It doesn't exist yet.
A stable version of Perl 6 is still a few years away. When it emerges however, it will bear approximately the resemblance to Perl 5 that a Lamborghini Countach does to a Volkswagen Beetle (well, the new one, anyway). (Which is to say, backward compatibility has been prioritized beneath new capability for the first time in Perl development.)
Don't panic. Perl 4 hung around for an indecent time after Perl 5 came out and Perl 5 will be ported, maintained, and improved for many years after Perl 6 emerges. The recently started Ponie project (<http://www.poniecode.org>) will enable Perl 5 to run on top of the Parrot engine underlying Perl 6. Your Perl 5 programs will quite likely keep working as long as you do.
This book will be applicable in large measure to Perl 6 in any case; most of the Perl 6 magic involves not removing existing features, but adding cool new ones.
