Comments on: Too Easy or Too Hard

By: Jean Combs

Jean Combs — Fri, 24 Dec 2010 02:33:33 +0000

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.

By: Alex Balhatchet

Alex Balhatchet — Fri, 08 Oct 2010 11:16:08 +0000

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!”

By: http://openid.aliz.es/anonymous

http://openid.aliz.es/anonymous — Fri, 01 Oct 2010 13:29:00 +0000

s{dotcom company London}
{dotcom company in London}

By: zeroaltitude

zeroaltitude — Thu, 30 Sep 2010 23:02:37 +0000

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.

By: Aristotle Pagaltzis

Aristotle Pagaltzis — Thu, 30 Sep 2010 22:23:02 +0000

Perl is almost magical in the brevity of its regular expression syntax

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.

By: chapel.ambrose

chapel.ambrose — Thu, 30 Sep 2010 01:22:46 +0000

- go away and Learning Perl and Intermediate Perl
+ go away and read Learning Perl and Intermediate Perl
Presumably. Very interesting article.
[ thanks, fixed - Dave ]

By: sageword

sageword — Thu, 30 Sep 2010 01:17:18 +0000

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.

By: zeroaltitude

zeroaltitude — Wed, 29 Sep 2010 21:33:54 +0000

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.