In defense of Perl.
Kickin’ it old school.
I started writing web applications around 1997. On Solaris. Using Netscape’s web server. In Perl.
My LinkedIn profile starts thusly:
I began working with LAMP back in the days where the men were men and we ate Perl for breakfast. Installing Linux with 40 floppy disks puts hair on your teeth. One thing led to another, and before I knew it I was living with an E-Commerce system. What can I say? I was young and needed the money.
Around 2001 I took a departure from the web world to work on enterprise and desktop software. Sure, I slung a little web code here and there, but I didn’t track the technology landscape like I did back in the good old days.
When looking at founding Directed Edge, it was time to re-approach the web and get back on friendly terms. Like an old-timer desperately trying to identify all that is hip, I set out to figure out what the cool kids were doing.
Python with Django and Ruby on Rails.
I learned bits of Python and Ruby, things I’d been meaning to learn for ages. Ruby’s syntax and I didn’t hit it off at first, so I spent a couple days reading Learning Python, which had been sitting on my shelves for a few months.
But friends, home is where the heart is, and even after getting a reasonable grasp on Python I kept going back to Perl. There are two reasons for this:
CPAN. Oh, sweet, sweet CPAN.
The CPAN has grown so large and comprehensive over the years that many people learning Perl seem to elevate it to a sort of mythical status, and express surprise when they begin to encounter topics for which a CPAN module doesn’t exist already.
CPAN is huge, easy to search, well documented, and trivial to deploy. Need some code to do TLS authenticaed SMTP tranfers? Trivial. Need a WSDL compiler to work with an old SOAP API? Up and going in a few minutes. Need to test a REST API with a really mature HTTP implementation? It’s there. Need code for quickly generating mail routing code for feedback processing? Bingo. But wait — that’s all pretty common stuff, right? There are even CPAN modules for stuff like tracking quantum superpositions in quantum computing algorithms or quickly building genetic algorithm implementations (my two research areas in college). And all under the same roof.
And let’s back up one bit; for all of the perceived culture of sloppiness, I earnestly believe that Perl has the strongest documentation culture of any major programming language. By and large CPAN’s 12,000-something modules are rather well documented with examples and gotchas in addition to the basic API docs. As a special bonus as soon as you’ve installed them with the command line cpan tool (which automatically resolves dependancies, downloads, tests and installs) they’re available in your system’s man pages. The standard man pages for core language features are great, and well written to boot. The Camel Book will forever have a place on the gilded streets of O’Reilly’s hall of fame as possibly the most enjoyable to read 1000+ page technical book ever written.
Fast hacks, fast, quickly.
Combined with the power of CPAN, Perl just has something about it that makes gruesome, and gruesomely fast hacks possible. Much of this is owing to CPAN solving 75% of the universe’s problems for you from the get-go. But Perl is something of the Sicilian mobster of the programming world — it gets stuff done.
Add to that that it’s one of the speediest scripting languages performance-wise, and it’s great for quick-and-dirty hacks that programmers invariably have to come up with on a regular basis. Perl seems to be optimized for writing as little code as possible to get the job done.
What I’m not saying.
Most people talking about Perl are quick to groan about its ugliness. I’ll first note, most of them don’t know Perl, so it’s my earnest belief that much of that is fadiness. Perl can be well written, but its syntactic moral flexibility means that there’s a lot of ugly Perl out there. I’m not going to try to pass that off as a good thing. But a real Perl mensch can write Perl that’s as easy to read as code in most other popular programming languages.
I’m also not advocating doing large projects in Perl. In a decade of Perl slinging, it’s only happened a time or three that I written tools that were more than a couple thousand lines of code. (But again, the beauty lies in that I’ve rarely needed to.) Nothing particularly central to Directed Edge is written in Perl, but it’s been my Swiss Army Chainsaw on the fringes — converting data formats, processing simple forms, interfacing with databases — glue code, basically.
And there I have to say, despite wanting oh-so-desperately to be one of the Python cool kids, I think Perl is there to stay.
Michael Campbell:
Wasn’t aware perl needed defending, but nice article all the same.
August 3, 2008, 8:37 pmCharles Ju:
I agree, but you should check out Ruby on Rails again. It’s not so much a fad, but rather it’s a new way of programming. Sure all those things above are nice (and Ruby actually has something similar to CPAN, RubyForge).
http://www.oreillynet.com/ruby/blog/2007/09/rubyforge_vs_cpan_1.html
August 3, 2008, 9:00 pmchromatic:
@Charles,
Daniel’s comparison of the CPAN to RubyForge was highly suspect, and the conclusion you seem to have drawn from it is ridiculous. Look at both (and use both) and tell me that’s a real comparison.
August 3, 2008, 10:02 pmlee doolan:
>> It’s not so much a fad, but rather it’s a new way of programming.
Ahhh-HAHAHAHAAH. OOHHH-HOHOHOHOHOHO.
You’re really funny.
August 3, 2008, 10:15 pmMark:
Michael, what rock have you been living under?
August 3, 2008, 10:37 pmwhat?:
lol, linkedin?
August 4, 2008, 12:12 amMichael:
My only argument against perl would be it looks like a chicken ran across your keyboard.
August 4, 2008, 3:17 ammarkus:
CPAN is a valid argument. Personally I think it is overrated, but on the other hand you can see clearly that at one point in time there were legions of perl hackers.
Most of these fossil dinosaur hackers still exist. They are C experts in most cases too. You can’t persuade most of these hardcore to try out python or ruby.
I however do not accept the notion that perl is so much faster than say python or ruby (with ruby being the slowest).
The thing is, speed in executing is really pointless by these languages. C will beat them all any time.
What is important is maintenance. And building an ecosystem.
Personally I have settled for Ruby - yes, Ruby. Not “Ruby on Rails” because I do not care to use a specific framework.
Ruby is a lot more elegant than perl IMHO, and python is more readable
than perl as well. I think it is a shame that people still help perl grow with its horrible syntax.
On a more “neutral” agenda, I think there should exist a “common” cpan for all scripting languages. It is silly and a waste of resources that one has to port between different languages.
Let everyone choose the language they want, and everyone is happy.
August 4, 2008, 4:22 amquirkyalone:
“Fast hacks, fast, quickly.”
Temptation or real advantage?
August 4, 2008, 5:40 amMatt S Trout:
Actually, we use perl for moderate size projects quite happily. (and what other people see as “large projects” we tend to see as a bunch of moderate size projects communicating via well-defined APIs
perl’s Catalyst framework scales happily to the 10k LOC mark in projects I’ve worked on (spread through several hundred classes); it aims at the sort of projects where rails might be faster for the first 10% but just wouldn’t cut it further on - we have a fair few users who use Catalyst, rails -and- django depending on what sort of project they’re working on since each has its sweet spots (and it’s these people who tell me rails isn’t nearly as nice at that scale, so this isn’t just blind fanboyism - they still happily use rails over Catalyst for the smaller stuff where it -is- quicker).
The big problem we suffer as a community is that people seem to find it fashionable to beat on perl based on a groupthink derived from decade-old CGI coding practices that focused on getting the most out of a single mad but brilliant developer with his own idiomatic style, whereas the “new wave of CPAN” movement (Catalyst, DBIx::Class, Moose et. al.) focuses on exposing the power of the language in a way that encourages there being many ways to do it, but one you should use by default in the name of code re-use and ease of maintenance. Sadly, too many people have written perl off without even studying modern best practices - just as a couple years back java was being written off for the failings of the J2EE stack even while much better alternatives were going into production all over the place.
Never mind. We’ll just keep making our customers happy and helping support the development of the tools that allow us to do so.
August 4, 2008, 7:58 amHugh Myers:
Virtually all comments about how hard to look at/read/whatever perl is are directly connected to regular expressions. Since the preferred language of all of these critics use perl style regxen, I wonder about their accuracy and bias.
August 4, 2008, 10:04 amTyzanne:
CPAN is also not something you should ever use if configuration management is important to you. They can update things midstream and you aren’t guaranteed to have the same version on any two machines. Also, the settings could be wrong, and even worse, dependencies can and do break frequently and cause you a lot of pain trying to figure out how to get something to install properly. Use DAG RPMs or build your own and stay far, far away from CPAN if you have more than one machine.
August 18, 2008, 12:08 am