Section 1.2. What Does

1.2. What Does "Perl" Stand For?

Perl is sometimes called the "Practical Extraction and Report Language" though it has been called a "Pathologically Eclectic Rubbish Lister" among other expansions. It's a retronym, not an acronym since Larry Wall, Perl's creator, came up with the name first and the expansion later. That's why "Perl" isn't in all caps. There's no point in arguing which expansion is correct; Larry endorses both.

You may also see "perl" with a lowercase p in some writing. In general, "Perl" with a capital P refers to the language and "perl" with a lowercase p refers to the interpreter that compiles and runs your programs.

1.2.1. Why Did Larry Create Perl?

Larry created Perl in the mid-1980s when he wanted to produce some reports from a Usenet news-like hierarchy of files for a bug-reporting system, and awk ran out of steam. Larry, being the lazy programmer that he is,^[*] decided to overkill the problem with a general-purpose tool that he could use in at least one other place. The result was Perl Version zero.

^[*] We're not insulting Larry by saying he's lazy; laziness is a virtue. The wheelbarrow was invented by someone who was too lazy to carry things; writing was invented by someone who was too lazy to memorize. Perl was invented by someone who was too lazy to get the job done without inventing a whole new computer language.

1.2.2. Why Didn't Larry Just Use Some Other Language?

There's no shortage of computer languages, is there? But, at the time, Larry didn't see anything that met his needs. If one of the other languages of today had been available back then, perhaps Larry would have used one of those. He needed something with the quickness of coding available in shell or awk programming and with some of the power of more advanced tools like grep, cut, sort, and sed,^[] without having to resort to a language like C.

] Dont worry if you don't know what these are. All that matters is that they were the programs Larry had in his Unix toolbox, but they weren't up to the tasks at hand.

Perl fills the gap between low-level programming (such as in C or C++ or assembly) and high-level programming (such as "shell" programming). Low-level programming is usually hard to write and is ugly but fast and unlimited; it's hard to beat the speed of a well-written low-level program on a given machine. There, you can do almost anything. High-level programming, at the other extreme, tends to be slow, hard, ugly, and limited; there are many things you can't do with the shell or batch programming if there's no command on your system that provides the needed functionality. Perl is easy, nearly unlimited, mostly fast, and kind of ugly.

Let's take another look at those four claims we made about Perl:

First, Perl is easy. As you'll see, though, this means it's easy to use. It's not especially easy to learn. If you drive a car, you spent many weeks or months learning that, and now it's easy to drive. When you've been programming Perl for about as many hours as it took you to learn to drive, Perl will be easy for you.^[*]

^[*] But we hope you'll crash less often with the car.

Perl is nearly unlimited. There are few things you can't do with Perl. You wouldn't want to write an interrupt-microkernel-level device driver in Perl (though that's been done), but most things that ordinary folks need most of the time are good tasks for Perl from quick little one-off programs to major industrial-strength applications.

Perl is mostly fast. That's because nobody is developing Perl who doesn't also use it, so we all want it to be fast. If someone wants to add a feature that would be cool, but it would slow down other programs, Larry is almost certain to refuse the new feature until we find a way to make it quick enough.

Perl is kind of ugly. This is true. O'Reilly's symbol for Perl is the camel, the animal on the cover of the venerable Camel book (also known as Programming Perl), a cousin of this Llama (and her sister, the Alpaca). Camels are kind of ugly, too. But they work hard, even in tough conditions. Camels get the job done despite all difficulties even when they look bad and smell worse and sometimes spit at you. Perl is a little like that.

1.2.3. Is Perl Easy or Hard?

Perl is easy to use, but sometimes hard to learn. This is a generalization, of course. In designing Perl, Larry made many trade-offs. When he's had the chance to make something easier for the programmer at the expense of being more difficult for the student, he's decided in the programmer's favor nearly every time. That's because you'll learn Perl only once, but you'll use it again and again.^[] Perl has any number of conveniences that let the programmer save time. For example, most functions will have a default; frequently, the default is the way youll want to use the function. So, you'll see lines of Perl code like these:^[]

] If youre going to use a programming language for only a few minutes each week or month, you'd prefer one that is easier to learn since you'll have forgotten nearly all of it from one use to the next. Perl is for people who are programmers for at least twenty minutes per day and probably most of that in Perl.

^[] We wont explain it all here, but this example pulls some data from an input file or files in one format and writes some of the data out in another format. All of its features are covered in this book.

     while (<>) {       chomp;       print join("\t", (split /:/)[0, 2, 1, 5] ), "\n";     } 

Written out in full, without using Perl's defaults and shortcuts, that snippet would be roughly ten or twelve times longer, so it would take longer to read and write. It would be harder to maintain and debug, too, with more variables. If you know some Perl, and you don't see the variables in that code, that's part of the point. They're all being used by default. But to have this ease at the programmer's tasks means paying the price when you're learning; you have to learn those defaults and shortcuts.

A good analogy is the proper and frequent use of contractions in English. Sure, "will not" means the same as "won't." But most people say "won't" rather than "will not" because it saves time and because everybody knows it and it makes sense. Similarly, Perl's "contractions" abbreviate common "phrases" so that they can be "spoken" quicker and understood by the maintainer as a single idiom, rather than a series of unrelated steps.

Once you become familiar with Perl, you may find yourself spending less time getting shell quoting (or C declarations) right, and more time surfing the Web, because Perl is a great tool for leverage. Perl's concise constructs allow you to create some cool one-up solutions or general tools (with minimal fuss). You can drag those tools along to your next job because Perl is highly portable and readily available, so you'll have even more time to surf.

Perl is a high-level language. That means that the code is dense; a Perl program may be around a quarter to three-quarters as long as the corresponding program in C. This makes Perl faster to write, read, debug, and maintain. It doesn't take much programming before you realize that when the entire subroutine is small enough to fit on-screen all at once, you don't have to keep scrolling back and forth to see what's going on. Since the number of bugs in a program is roughly proportional to the length of the source code^[*] (rather than being proportional to the program's functionality), the shorter source in Perl will mean fewer bugs on average.

^[*] With a sharp jump when any one section of the program exceeds the size of your screen.

Like any language, Perl can be "write-only" in that it's possible to write programs impossible to read. But with proper care, you can avoid this common accusation. Yes, sometimes Perl looks like line noise to the uninitiated, but to the seasoned Perl programmer, it looks like the notes of a grand symphony. If you follow the guidelines of this book, your programs should be easy to read and maintain, and they probably won't win The Obfuscated Perl Contest.

1.2.4. How Did Perl Get to Be So Popular?

After playing with Perl a bit, adding stuff here and there, Larry released it to the community of Usenet readers, commonly known as "the Net." The users on this ragtag fugitive fleet of systems around the world (tens of thousands of them) gave him feedback, asking for ways to do this, that, or the other thing, many of which Larry had never envisioned his little Perl handling.

As a result, Perl kept growing. It grew in features. It grew in portability. What was once a little language available on only a couple of Unix systems has grown to have thousands of pages of free online documentation, dozens of books, several mainstream Usenet newsgroups (and a dozen newsgroups and mailing lists outside the mainstream) with an uncountable number of readers and implementations on nearly every system in use today. And don't forget this Llama book as well.

1.2.5. What Is Happening with Perl Now?

Larry doesn't write the code these days, but he still guides the development and makes the big decisions. Perl is mostly maintained by a hardy group of people called the Perl 5 Porters. You can follow their work and discussions on the [e-mail] mailing list.

As we write this (March 2005), a lot is happening with Perl. For the past few years, many people have been working on the next major version of Perl: Perl 6.

Don't throw away your Perl 5, which is still the current and stable version of Perl. We don't expect a stable version of Perl 6 for a while yet. Perl 5 won't disappear when Perl 6 shows up, and people may end up using both for several years. The Perl 5 Porters maintain Perl 5 just like they always have and some of the good ideas from Perl 6 have made it into Perl 5.

In 2000, Larry Wall first proposed the next major release of Perl as the Perl community's rewrite of Perl. In the years that followed, a new interpreter called Parrot came to life, but not much else happened for average users. This year, Autrijus Tang started playing with Pugs (Perl User Golfing System) as a "featherweight" implementation of Perl 6 in Haskell. Developers from the Perl and Haskell sides of the world ran to help. We can't say what will happen since they are still working on it, but you can write simple Perl 6 programs in Pugs. You can see more about Perl 6 at http://dev.perl.org/perl6 and http://www.pugscode.org/ to get more information.

1.2.6. What Is Perl Good For?

Perl is good for quick-and-dirty programs that you whip up in three minutes. Perl is also good for long and extensive programs that take a dozen programmers three years to finish. Of course, you'll probably find yourself writing many programs that take you less than an hour to complete, from the initial plan to the fully tested code.

Perl is optimized for problems that are about 90% working with text and about 10% everything else. That description seems to fit most programming tasks that pop up these days. In a perfect world, every programmer could know every language; you'd always be able to choose the best language for each project. Most of the time, you'd choose Perl.^[*] Though the Web wasn't even a twinkle in Tim Berners-Lee's eye when Larry created Perl, it was a marriage made on the Net. Some claim the deployment of Perl in the early 1990s permitted people to move lots of content into HTML format rapidly, and the Web couldn't exist without content. Of course, Perl is the darling language for small CGI scripting (programs run by a web server) as well, so much so that many of the uninformed still make statements like "Isn't CGI just Perl?" or "Why would you use Perl other than for CGI?" We find those statements amusing.

^[*] Don't take our word for it, though. If you want to know if Perl is better than language X, learn them both and try to see which one you use most often. That's the one that's best for you. In the end, you'll understand Perl better because of your study of language X, and vice versa, so it will be time well spent.

1.2.7. What Is Perl Not Good For?

So, if it's good for so many things, what is Perl not good for? Well, you shouldn't choose Perl for making an opaque binary. That's a program that you could give away or sell to someone who then can't see your secret algorithms in the source, and thus can't help you to maintain or debug your code. When you give people your Perl program, you'll normally be giving them the source and not an opaque binary.

If you're wishing for opaque binaries, though, we have to tell you that they don't exist. If people can install and run your program, they can turn it back into source code in any language. Granted, this won't necessarily be the same source that you started with, but it will be some kind of source code. The real way to keep your secret algorithm a secret is, alas, to apply the proper number of attorneys; they can write a license that says, "You can do this with the code, but you can't do that. And if you break our rules, we've got the proper number of attorneys to ensure that you'll regret it."