We hear a lot of people complaining that programming in Perl is too difficult, but I think that a lot of these problems stem from people making the opposite assumption – that writing Perl is easier than it actually is. Let me share a couple of examples. I’ve lightly disguised the companies in question – so if you think you recognise a place where we’ve worked together you’re probably wrong.
In the first, I’m working for a global organisation. Most of their bespoke software is written in Java, but (like pretty much every company) there are a few Perl programs running vital parts of the infrastructure. This company have also outsourced a lot of their maintenance work to another company in India. This Indian company has dozens of people who are dedicated to working on my client’s systems. But they are Java programmers and every once in while they need to do some work on a Perl program.
This company has an internal IRC network and there’s a Perl channel which I keep half an eye on whilst getting on with my work (which is maintaining a huge Perl program). A few times a day one of these Java programmers turns up on the Perl channel explaining a problem they have to solve in a Perl program and asking for help. In pretty much every case, the problem boils down to the Java programmer having major misconceptions about how Perl works. Perl programmers on the channel try their hardest to to help, but it’s often a frustrating experience. Usually the correct answer is “go away and read Learning Perl and Intermediate Perl, then you will understand how the code works”. But these programmers don’t have the time to do that. They need this task finished in an hour. Often it’s a task that could be easily achieved in an hour – but only after you’ve done the groundwork of understanding how Perl works.
The problem this company had was that Perl wasn’t seen as being as important as it actually was. People in the Indian company saw it as a “scripting language” that any of their (no doubt highly qualified) Java programmers would be able to use without any preparation or training. That’s clearly not the case.
But, I hear you say, that’s not fair. Perl and Java are really different languages. I’m glad you pointed that out as it’s a nice link to my second example.
In this example, I’m working for a dotcom company in London. Like so many dotcom companies they have a Perl codebase that was thrown together five years ago in a couple of months by people who didn’t really know what they were doing. This company has the added problem that they are finding it hard to recruit people with Perl experience. So they start recruiting people with experience of languages like Python and Ruby in the belief that these languages are so similar that the programming skills are completely interchangeable.
And, of course, Perl, Ruby and Python are all a lot closer to each other than they are to languages like Java. But there are differences. Important differences that aren’t just syntactic. I can read Python and Ruby just fine. But if I got a job where I had to write a lot of either of those languages, I wouldn’t assume that I could just pick it up by osmosis, I’d get a book and read about the language. If I was going permanent at the company, I might even suggest that they send me on a training course.
Conversations with these non-Perl programmers often took a predictable course. They’d start complaining that the code was hard to read. This was hard to counter as a lot of the code was horrible. But if you pointed out some of the newer and better code, they wouldn’t see the improvement. They would insist that somehow Ruby or Python code was inherently easier to read than Perl code. I’d try to point out that Perl programmers find Perl code as easy to read as Python (or Ruby) programmers find Python (or Ruby).
So there seems to be this perception that Perl should be as easy to read as Random Programmer’s favourite language. And I don’t understand why that is. Just because I’ve been programming for almost thirty years, I don’t expect to be able to program in any language I happen to look at – well, certainly not well enough to be paid for doing it.
I’m not sure what we can do to counter this misconception. I think it probably stems from the late 90s when everyone was writing Perl. And if everyone is doing something, then it must be really easy.Of course, most people were writing really horrible Perl because Perl isn’t as easy as they thought it was.
Not sure it’s possible to sum this up in a simple marketing slogan. “Perl is Easy (but not as easy as you think)”.
This is an interesting post. I think it covers a lot of ground — it certainly strikes me as true that there are lots of people going from language A to language B who make the mistake of thinking that language B should be inherently familiar on the basis of language A.
However, I also think that there is something missing from this post. Take for example me. I have programmed in Perl pretty consistently for about 13 years. I wouldn’t call myself a language expert, but I’m pretty familiar with some of the fancier bits. I also have done a lot of programming in C, Python, Java and Javascript. Each language has its dominant metaphors and patterns, and they’re all quite different in important, deep ways.
Each of these languages can house good and bad code. However, if pressed, I would admit that even to me, even though Perl was my first programming language, even though I find Perl’s power dizzying, that it is a harder language for me to read than the others I’ve programmed in. There are a few reasons for this.
The first reason is that Perl, unlike the other languages, has very important subtleties that simply make reading it hard. For example, there is the well-known and oft encountered issue that named closures stated in any old scope are automatically global. (See http://perl.apache.org/docs/general/perl_reference/perl_reference.html#Understanding_Closures____the_Easy_Way) That just makes code that uses named closures intrinsically harder to understand — as with any special-casing of a language rule. Or take the way that a famous perl module manages to define try {} catch {} because of the trick that if you define a subroutine as taking a coderef (equivalent to block? not exactly…), you can seem to magically change the language itself (but don’t forget that the brace has to come on the same line as try, those of you with difference indenting practices…). I can’t think of as many, or as deep, of these language subtleties in the other languages I am familiar with. That could be a bias, I suppose, but I wasn’t ever making the claim that these are universal truths — I am just reporting my own experiences.
The second reason is simply syntactic. I take two things for granted, and they might just be idiosyncracies I have, or they might be more interpersonal truths. 1. Having language markers for variable types is hard to read. 2. Brevity has the innate potential for hard-to-read. For 1, I like to think about Perl’s variable typing. Perhaps everyone but me looks at @{${foo}bar}[\$coderef] and nods sagely in perfect understanding, but for me, it always causes a mental processing delay. Or if you prefer more prosaic examples, simply wonder aloud someday why a hash slice starts with the ‘@’ symbol. It makes sense, for sure, but the question wasn’t whether the language was rational, it was whether it is easy to read. Similarly for the case of brevity. Perl is almost magical in the brevity of its regular expression syntax — far and above the best language for syntactic parsing that I am aware of. But Perl is famously also difficult to read in this regard, and I think that this is because compactness of expression has the inherent potential of being difficult to read.
Well I suppose I’ve gone on too long as it is. In any case, I just wanted to point out that in my own judgment, I do not think it is arbitrary that people call Perl a “write-only” language. And I don’t think it is merely because people are not familiar with Perl. I think that if we had to openly and honestly assess each language’s strengths and weaknesses, Perl, at least pre-6, does have a little bit of owning up to do on the issue of readability.
Your examples remind me of the old Unix truism (and sig-line): “Unix is user-friendly; it’s just selective on who it’s friends are.”
I’d never thought about it until your article, but that applies remarkably well to perl. One *wizard* friend has occasionally been overheard saying “Perl is a write-only language.”
Having said that, any excuse an employer CAN use to avoid training costs, they generally will use. That should rank up with ‘expert in an orthogonally different language’ as why shops end up with coders that can’t grok perl. Bad HR and training policies can fix both.
A last thought: I’ve never seen an enterprise Java shop that didn’t smell vaguely dysfunctional.
– go away and Learning Perl and Intermediate Perl
+ go away and read Learning Perl and Intermediate Perl
Presumably. Very interesting article.
[ thanks, fixed – Dave ]
Regular expressions were invented long before Perl, and exist in every single modern language. The only difference to other modern languages is that Perl goes out of its way to make them non-painful to actually use.
Hi Aristotle,
I thought it would be clear, but here is a clarification: my point wasn’t about the regular expressions themselves, but about the operators =~, !~ and the like, and the variables they create, $1, etc. Python doesn’t even come close to this kind of awesome power-with-compactness, even though the regular expressions themselves are admittedly the same.
s{dotcom company London}
{dotcom company in London}
Great post, very interesting stories. As someone who’s only had one job since I graduated I always find it enlightening reading about the differences and similarities of other people’s working experiences 🙂
I am in a somewhat similar situation to your second anecdote, except that we have only hired non-Perl guys into internship/short-term positions. It sounds like the main problem is that the newly hired Ruby/Python/PHP guy still thought of themselves as a Ruby/Python/PHP guy, and so they were always comparing Perl to their language of choice. If somebody is hired as a full time Perl programmer, then they should start thinking of themselves as a Perl guy, and stop comparing one language to another! There are many many benefits to being a Perl guy: the amazing community, YAPC, Buffy, pie, etc. They should embrace it, as should the other existing Perl programmers in the company.
Basically, I agree with your point, assuming your point is “if you get hired for a Perl job, go learn Perl properly!”
Your examples remind me of the old Unix truism (and sig-line): “Unix is user-friendly; it’s just selective on who it’s friends are.” I’d never thought about it until your article, but that applies remarkably well to perl. One *wizard* friend has occasionally been overheard saying “Perl is a write-only language.” Having said that, any excuse an employer CAN use to avoid training costs, they generally will use. That should rank up with ‘expert in an orthogonally different language’ as why shops end up with coders that can’t grok perl. Bad HR and training policies can fix both. A last thought: I’ve never seen an enterprise Java shop that didn’t smell vaguely dysfunctional.