Farewell Perl

This post is inspired by this post, describing why Perl "didn't win". I think that's being generous: Perl screwed up in a big way, and they did so in classic open-source (and closed-source) fashion, by focusing too much on the tech, and not enough on the value.

Before we begin, though, let me make my biases clear: I am not a Perl fan. The irony of being the #2 hit for "Perl lover" on Google (today, #4, I just checked) is so loud as to be deafening. I have never liked Perl. I was writing code in the late 90's, during Perl's heyday, but I freely admit that I was a C++ bigot (and by 1997, a Java bigot) through and through. I saw no real reason to use this hacked-up language that had no official language distribution, no official language specification, and (most of all) didn't really work all that well on Windows. (Yes, I was Windows-bound more or less during those days, and not because I couldn't fire up a Linux instance--I'd been exposed to Linux as far back as 1988, when my best friend at the time brought over the 25 or so floppies with the core 0.99 patch level whatever Linux distribution on it. I was Windows-bound because I liked it. And OS/2. And WindowsNT, when it came out, too.)

But my real disdain for the language came during the first FOO camp. FOO camp was the "Friends Of OReilly camp", and it was a "c'mon over to our corporate headquarters, spread out a tent or sleep in a cube, and meet a bunch of other folks" invitation from the editors and owners at OReilly and Associates. I was lucky to be invited (my invite came courtesy of the senior .NET editor at the time, John Osborn, because I was working on the Rotor book. I packed up myself and my son, Michael, and we made the drive into the Bay Area from Davis, where I was living at the time. A bunch of the NFJS speakers were there, too (like 8 of us, as I recall--there's a photo somewhere of all of us), and I was thrilled to see that Peter Drayton (my C# In A Nutshell co-author and fellow DevelopMentor alum) and Brad Merrill (the "language evangelist" for the recently-announced .NET platform) were also there.

When it turned out that Larry Wall (Perl's creator), chromatic and Allison (last name forgotten, sorry), core Perl committers who were hard at work defining a new VM for Perl (what would later be called Parrot--I can't remember if that was its name at the time) were also there, an impromptu session around language runtimes was quickly put together. We had Dave "Ruby Dave" Thomas, Brad, Peter, myself, and the three Perlers, and it was going to be an interesting discussion, for sure. We had all the major VMs of the time represented: Ruby (Dave), Java (me), CLR (Brad, Peter and I), and of course the Perl folks.

But about ten minutes in, as the non-Perlers were listening to the Perl folks talk about their as-yet-to-be-written VM implementation, several little tidbits had Peter, myself, and Brad sort of glancing at each other with some raised eyebrows. The Perl folks just didn't seem... to GET it. Defining a virtual machine interface is not trivial, particularly if you want it to be across different languages, and they just didn't seem to understand the level of work they were proposing, particularly if they wanted it to be an interoperable environment. I remember Dave in particular trying to understand their approach: "So if a Ruby program creates a hash, what is created?" "Well, an instance of a Ruby hash is created." "OK, so then if I pass that Ruby hash to a Perl program, what gets passed?" "Well, it's a hash, so it'll be a hash when the Perl program receives it." "A Ruby hash, or a Perl associative array?" "I don't see what's so hard to understand about this--it's just a hash." And so on. Larry was particularly quiet, allowing chromatic to carry most of the conversation, and Alison to sort of chime in here and there almost as a supporting cast member or chorus or cheerleader or something. (Don't get mad at me, folks, for making a sexist comment--she was plenty sharp, it sounded like, she just fully agreed with everything chromatic was saying and wasn't really putting any new ideas into the conversation.) As the conversation wore on, though, and first Brad, then Peter and I, then even Dave, tried to explain that you needed some kind of bare-minimum understanding of a core type system across all these languages if you wanted this idea to work, Larry started to look (in my mind) a little haunted and a little concerned, like, "Wait, are we missing something here?" I don't remember chromatic or Alison ever having that look in their eyes, and in fact I remember them being quite stubborn about it, convinced that they could safely ignore the collected wisdom of three platforms and a dozen or so interoperating languages on those platforms and just hack it all to work.

That was when I lost all respect for Perl and realized it was probably doomed to failure.

Oh, I admit it: I've been chortling in a pretty disgusting and ungracious way as Perl has slowly and spectacularly collapsed. It's a character flaw that I'm taking such glee in watching the whole thing slowly slip under the waves like the Titanic. You can hate me for it, and I'll agree with you whole-heartedly. And I'm not changing one iota.

The Big Blue Marble post (sorry, I can't find any other author attribution on that post) nails a number of issues, but misses on a few more. For example, they're right when they say

Perl 5 also had a distinct advantage in the CPAN, a massive library of free software you can download, use, modify, and deploy in your own programs. Perl had this right for a long time. Perl advocates long argued (and some presumably still do) that the large library of CPAN is the reason to use Perl.
because having a huge ecosystem is clearly an advantage when choosing to use a language, as Java, NodeJS and Ruby have all discovered. (.NET developers, too, are starting to feel it.) But there's also such a thing as "too much ecosystem", as Java, NodeJS and Ruby have all discovered, when you feel paralyzed by the "embarrassment of riches" of libraries within an ecosystem. Does any language really need two dozen ORM implementations? Probably not, and yes, having so many to choose from allows the best ones to surface (in theory), but it also presents "analysis paralysis" when trying to choose one.

The other thing they sort of skate over, though, is that yes, when a language reaches a certain number of "absolute number of programmers", the large ecosystem of libraries is sure to follow.... But if Perl had this huge collection of code that anybody could use, how did Ruby, Python and Node (Perl's principal competitors, I would argue) get all those programmers? Surely there had to be some compelling reason to those three languages, something that Perl lacked, to bring people into those languages long enough to build those ecosystems?

They sort of touch on it in the section entitled "Maintenance and Greenfield Concerns are Very Different", but they really miss the true point, in my opinion: Perl lost programmers because (a) the fork of Perl 6 took a ton of momentum away from the language and produced no useful outcome or migration path or anything, but more importantly (b) the language, and programs written in that language, simply became too hard to maintain. Perl programs are routinely called "write-only" by those who left. Perl lovers insist that "if you wrote Perl the right way, you could write maintainable code". I believe them--the problem is, nobody did. Well, OK, maybe a few did, and those Perl programs did in fact see continued maintenance and extension, but most were just scraped together to scratch a particular itch, then left alone with zero docs and a whole slew of questions when the next guy/gal came along to try and make a tiny change to it.

And believe me, I hold no negative view of the Perl hacker who took this approach; this attitude came from the very top: Larry Wall proudly proclaimed for a while that Perl had no official language specification, and while we were at FOO camp he said that Perl 6 was going to be the first time he'd ever written one. A language that complex, without a spec, means that when you finally do write one, you're going to be trying to reverse engineer something as complicated as the human brain. Seriously. Particularly if you wanted to keep backwards compatibility, which was really a necessity if Perl was to maintain its momentum. I don't know when Larry gave up on that (if he did--I haven't looked for a long time), but I was watching for a few years, never saw one, and waited for the inevitable implosion afterwards.

In many respects, Perl was the ultimate hacker's language: hacked together from the beginning, enabling a ton of hacking to happen, and continuing to hack new features into the language as the hacker community supporting it thought they would be useful. And it's important to note Perl's slow slide beneath the waves.

Big Up-front Design isn't a panacea. But neither is hacking without a plan or a spec or any kind of visionary guidance. Perl needed a spec long before they finally tried to put one together. As I look out at Ruby, I wonder if the same thing is going on there, and if history is going to repeat itself before long. Python has a spec, or at least a mostly-benevolent dictator in Guido to run it. JavaScript (supposedly) has a spec with ECMA and the ES specifications, though how much movement we can practically see there (thanks to all the bazillions of old browsers out there) is debatable. But they at least have the specifications, and that provides that guiding principle and more importantly, the broader reach that equally-interoperable implementations can provide.

Perl didn't win because the Perl programmers thought they could defy pesky things like "architecture", "design" and "forethought". They hacked, and they hacked, and they made it work for a while, but in the end, inertia and technical debt set in, and while they were struggling to get out from underneath that, they lost the thing that made Perl worthwhile in the first place. They lost the "I can just get stuff done in it" tagline.

That's the value that any language brings: Can I get done what I need to get done? Does the language provide me some kind of compelling reason to use it? Ruby brings rapidity; JavaScript, ubiquity (and today, both client- and server-side presence); C++, "portability" and native execution on pretty much any platform you care to name; Haskell, "purity"; Java, .NET, server-side ubiquity and a wealth of enterprise options; and so on. (Notice I stay away from nebulous terms like "intuitive" or "beauty"; those are both in the eyes of the beholder, and what's intuitive to one is unintelligible to another, and vice versa.)

Perl lost that, and by doing so, lost.

RIP, Perl.