I’ve been reading a bunch of Perl blogs recently, which seem to have seen a flurry of activity following Matt Trout’s call to Perl people to get blogging and spread the word. Tied into the urgency of Trout’s call is a common refrain of “why don’t programmers like Perl?” John Napiorkowski asks why all the hate? (the answer, it turns out, is because he looks sort of cross in his profile picture), David Golden thinks people should stop with the perl golf, and Sam Crawley thinks that people dislike Perl because they’ve had to deal with badly written Perl code, as does Gabor Szabo.
Actually, the image of someone coming to loath Perl after having to maintain a heap badly written code is a recurring idea in these posts and comments. And I guess that’s because it’s an accurate image. Because everyone who’s worked with Perl has had to face that pile of crappy old code, and either he’s cursed it and sworn never to touch the stuff again, or he’s said to himself, I can do this better!
– and proceeded to write a fresh pile of clever Perl code, which he will find, a year or two down the road, has become to his horror another pile of ugly old code he is loath to maintain.
I’ve been programming Perl for a living for the past 9 years, and I’ve been dealt my share of heaps of bad code to maintain. I’ve also written some. And I came to realize, as I tried to scramble up their too-clever-for-my-own-good slopes that what I was climbing was someone else’s learning curve. And what I was leaving behind me was the detritus of my own education.
Perl is a complex language. By design. It’s filled with switches and toggles and shortcuts and magic, and a wondrous embedded mini-language of regular expressions, designed to make you feel sexually inadequate if you use four lines of code to parse a line of text instead of one. Conversely, Perl is missing some other pretty basic features which weren’t around when Larry was distilling it from the soul of Unix. Therefore it also has an elaborate set of workarounds and tricks to provide those missing features. People get beguiled into using all this stuff, and by using it learn how it can cut off their fingers: For example, why write ugly C-like || or && when you can write the more readable or or and? Well, because those operators have different precedence and are not interchangeable, and using the wrong one will bite you in the ass.
But getting bitten in the ass is how we learn; we learn new features by trying them out, getting past the obvious syntax and logic bugs needed to get our code to work, and letting the more subtle barbs slip by (Perl is marvelous at getting badly written code to Just Work). We call this DWIM – Do What I Mean – and while it is more useful, it’s no more trustworthy than a C++ compiler. To actually know what you’re doing with Perl, you need to see past DWIM to the subtleties, things like autovivification.
Another favorite Perl acronym is Perl’s motto, TMTOWTDI, There’s More Than One Way To Do It. CPAN is a magnificent edifice built to celebrate TMTOWTDI. Perl’s Object Oriented faculties are some syntactic sugar and a piece of string? Well, CPAN is overflowing with ways to create objects, classes, accessors, attributes, inheritance, prototypes, method exporters, roles, etc. etc. Testing frameworks? Templates? ORMs? Web frameworks? Other languages also have a selection of each, but how many of them include five subtly-different object models in each? Furthermore, Perl developers in CPAN seem to thrive on the novel: YAML! Source Filters! Prototype-based Inheritance, declarative syntax, cats and dogs living together, Attributes!
No wonder my boss likes to write (and has written) his own everything. But CPAN is not only a gaudy distraction, it’s an immensely useful resource, and for every non-trivial bit of code you want to do in Perl, you can bet anything that someone’s already done it, probably better than you could (simply because he’s cleaned his code enough to put it up online, where it’s possible for someone trying to use it for something that isn’t it’s original purpose to try it). There are many wonderful modules in CPAN, but learning about them, learning to use them, finding out about their hidden corner-cases and unexpected behaviors takes even more time, and the code you write while learning about CPAN modules is more code on the heap that someone will eventually need to maintain – which is particularly annoying if what you learn eventually is “I really shouldn’t have used that module for this”.
So, to summarize, Perl has by design a steep and scary learning curve. You can be productive in it pretty quickly – I see the sysadmins in the next office using it quite contentedly (it beats learning shell scripting, IMHO), but the code you write is supposed to mutate over time, as you learn and apply more of the language. Larry Wall often talks about Perl as equivalent to a natural language, and says how a five year old can use English properly, but you can’t expect a grown-up to speak like a five year old. In other words, most of the Perl code in the world, and even on CPAN, is written by pre-teens learning to express themselves.
This experience appeals to a certain mindset: programming Perl, you keep learning new things! And then there are new modules on CPAN which have some shiny New! Conceptual! Design! Because CPAN is written by people who have bought into the Perl mindset. This probably goes hand-in-hand with Perl’s “poor PR” – writing blog posts is boring, messing with RSS mashup frameworks that pull in half of CPAN is fun.
Steve Yegge’s Perl rant (a very insightful piece, and the more you know Perl, the more you’ll get out of it) makes the point (in passing) that Perl already has awesome hype and marketing, and that this marketing is aimed at directly at programmers. It’s clear to me that the reasons for Perl’s unpopularity are the same reasons it’s popular with the particular crowd that uses it. People hate Perl for the same reason we love it – because it makes us feel clever.
