Why I like Perl
I wrote this in an email to a colleague of ![[info]](http://p-stat.livejournal.com/img/userinfo.gif)
totherme's a while back, and have occasionally felt the need to refer to it since. Fortunately, I have a place where I can post my ill-informed ramblings for all the world to see, so here it is :-) It's an attempt to convince a computer scientist, who I believe comes from the Haskell/static typing camp, why Perl is worth learning.
[If you're not a computer scientist, the two chief reasons to learn Perl are (1) it's incredibly useful, (2) it's great fun. But I digress.]
In many ways, Perl occupies the opposite corner of design-space to Haskell. To a first approximation, Haskell proceeds from the question "what if everything we think we know about language design is right?", whereas Perl proceeds from the question "what if everything we think we know about language design is wrong?" Consequently, learning Perl is essential for any student of programming language design. It's not so obviously revolutionary now, because some of Perl's design decisions have since become accepted into the conventional wisdom, but there are still some surprises.
The original author, Larry Wall, was trained as a linguist; consequently, Perl takes inspiration from human languages more than it takes inspiration from mathematics (it's one of the few programming languages with pronouns, for instance). It also has no hesitation about borrowing good features from other languages: built-in hashes from awk, regular expressions from SNOBOL, Python's OO features, Lisp's closures, C's syntax, Ada's module system. This leads to a lack of consistency, but consistency is not rated very highly in the Perl community (There's More Than One Way To Do It). The default assumption is that the programmer (a) is competent, (b) uses the language regularly. Consequently, if there's a choice between maintaining consistency and providing some useful special case (particularly if it's a common special case), they'll often go for the latter. If you need a Perl-like language infrequently, Python occupies roughly the same niche but aims at consistency and simplicity. Python, though, lacks one of Perl's most interesting and useful features, which might be called implicit type coercion. From a Haskell perspective, if the Python interpreter encounters a type error involving basic types in your code, it will (safely) bug out at runtime with a helpful error message, but the Perl interpreter will attempt to recover by silently applying type coercion functions and continuing. If that sounds dangerous, it's because I've described it from the wrong viewpoint: from a Perl perspective, it means that you can largely ignore variable types when writing code, freeing up your mind to concentrate on your actual algorithm. I've written more about this point at http://pozorvlak.livejournal.com/47565.html .
The assumption that the programmer is competent manifests itself in other ways. One of Perl's mottos is "easy things should be easy, hard things should be possible", and so there are few limits on what you can do if you really try (though occasionally the mechanisms involved are a bit grubby and ad-hoc). From a Haskell perspective, this means that Perl code provides few guarantees. It's therefore essential that you read the documentation, and conversely that you provide good documentation for code that you write (this is considered part of the definition of competence). I read something by Cale Gibbard a while ago about how he'd made a big change to some Haskell module without ever reading the docs, simply by checking that everything compiled and the tests passed. In the Perl world, this would be somewhere between impossible, inconceivable and criminally negligent :-)
The downside of providing freedom for good coders to do wizardly things is that it makes it possible for bad coders to do stupid things. This is unfortunate. The solution is held to be self-discipline and education, and not hiring bad coders in the first place.
Perl is the Practical Extraction and Report Language, and a lot of its features are there to help with everyday scripting, data-munging and administration tasks, particularly in a Unix environment. In particular, there are a lot of features there to help with writing "one-liners". A lot of people say that this makes it unsuitable for writing large programs; this was true for versions 1-4, but version 5 improves the situation here a lot. People can and do write maintainable Perl 5 programs that are hundreds of thousands of lines long. It's also worth mentioning that you can do a lot more in 1000 lines of Perl than you can in 1000 lines of, say, Java. If people say negative things about Perl, it's always worth asking which version they used: if they say 4 or less, you can safely ignore them. Perl 6, a major redesign, has been on the cards for quite a few years now, and it should iron out some of the language's more irritating quirks while incorporating some nifty things from Haskell and Lisp. Unfortunately, they're learning the Mozilla Lesson that ground-up rewrites take a lot longer than you'd think. They seem to be making good progress now, though, and some useful Perl 6 features have been incorporated in version 5.10.
[ykokese from Reddit makes an excellent point: "I believe learning that you can shoot a problem with a one-liner is important too. I'm not trying to be witty, I truly think that Perl marked the beginning of an era by making it possible to solve problems an order of magnitude faster than before, and indeed introduced the stop-messing-around paradigm."]
I should certainly mention CPAN, the Comprehensive Perl Archive Network, which is without doubt the world's largest collection of open-source user-contributed add-on modules, widely mirrored and with a nifty tool for recursively downloading and installing modules. There is almost always a CPAN module to help with whatever task you are attempting. It might not be good, mind, but it's almost certainly going to be easier to start with some CPAN module than roll your own solution. And at their best, CPAN modules are stunningly good (the parser generator Parse::RecDescent springs to mind, here, but there are so many good ones - have a look at Mark Fowler's Perl Advent Calendars for some more recommendations). Perl's paradigm-agnosticism helps here, too: if it makes sense for a module to be OO, it can be OO; if it makes sense for it to be functional, it can be functional; if it makes sense for it to be a bunch of imperative procedures, it can be. All in all, it's the world's premier laboratory for add-on module design and implementation :-)
It's not all roses: Perl definitely has its irritating quirks and defaults-that-shouldn't-be. A while ago, I tried to think of five things I hated about the language and came up with ten. See http://pozorvlak.livejournal.com/49333.html for the list.
If you're interested in learning it, I've posted some advice on resources at http://pozorvlak.livejournal.com/58387.html . I'd also be happy to answer any questions. But since you're in London, you should seriously consider subscribing to the London Perl Mongers mailing list (london.pm.org), or going along to some of their meetings - there are some awesomely good programmers in that group, and they're a pretty friendly bunch. London.pm tech meetings are a great way of opening your eyes to how much is possible.
[Note: I specify London.pm mainly because I used to be a member and can personally vouch for their excellence. Your local Perl M[ou]ngers group may well be just as good, and is certainly worth looking at.]
Some of the stories in Memories of 20 years of Perl may also help convince you to take a look. I especially like the story in the second comment. Larry Wall's speech Perl, the first postmodern computer language is also compulsory reading.
I hope that helps!
