I like this story from TorgoX's experience with BASIC.

His story sounds a lot like my experience with FORTRAN.

Lots of things are read-only. :)

Oh my bob. That's one of the best (and definitely the scariest) programming stories I've heard. I hope I'll never have to do something like that...

You're quite correct about the title. Mea culpa.
And the fact that it's people who don't know perl who say that it's read-only annoys me to no end as I try to do my best and not speak about something I don't know anything about myelf.

It's a subject that's been done to death, I'm afraid.

Bottom line is that you can write crappy code in any language but the low barrier to entry that Perl provides, combined with its popularity, may be said to encourage amateurs.

Not a bad thing, everyone has to start somewhere. When you come across someone writing this stuff send them here. They'll either freak out and turn to PHP or learn the error of their ways.

Good points all. But I don't think anything in the current universe would make the one who spurred this train of thought convert to perl. He prefers shell mainly ("shell is beautiful" according to him) or PHP for web.

Having written a twenty+ page shell script that's in use all over my workplace, I can relate to his muse.

Were the question to be phrased, "If you had to choose just one existing language to serve all your needs, what would it be," I think he'd choose Perl too. You should also point out that his shell programs use a lot of tools that are not themselves written in shell script.

Ask him how happy he'd be without grep and awk! :D

Really? A shell programmer complaining about Perl's readability? That's just silly :)

More people are killed every year by pigs than by sharks, which shows you how good we are at evaluating risk. -- Bruce Schneier

But as far as coding goes the Camel book (Programming Perl ISBN 0596000278) has a whole chapter devoted to different programming techniques in perl to promote:
- maintennance efficiency
- programmer efficiency
- execution efficiency
- and others..

You really are punishing yourself if you don't buy this book. Not only does it cover this very topic well but it covers the whole language.

And even better, I enjoy reading this book beside my bed at night. Why? Because the language used is thoroughly enjoyable. The author of this book proves, once and for all, that programmers are not nerds lacking in real-world skills! I have a good chuckle because the book is intelligent and witty.. and there is the odd embedded joke that only someone who has indulged in PCs most of their lives would understand.

Enough said. Buy the book, seriously. It's the best US$40 you'll ever spend on Perl.

Oh, don't you worry, I wuv my camel book. In fact, the camel book is the only book I used to learn perl, and it's the best learning experience I've had yet.
As a matter of fact I've tried to learn some python a few times by using the online tutorial at python.org, but all that tutorial does to me is annoy me so much I just close my browser and do some perl instead.
And you're right about clever stuff being incomprehensible at first. But the brain can be helped a bit on its way by not doing in 1 200 character line what you can do in 5 60 character lines.=)

Agreed on how great that book is. In fact, when I say "For Perl 5, I would read the manpages similarly [over and over again]" in Perl 6 through diffusion, I mostly mean the Camel Book. And a little of the actual manpages.

I think that one of the principal reasons behind Perl's "write-only" reputation is that it is so rich, i.e. TIMTOWTDI (which is arguably one of its strengths as well). I don't see any short-term solution to improving Perl's reputation in this regard. One may come up with a mini-Perl dialect (as I describe here) that, by virtue of being simpler (and more limited), would also be easier to read, but at best this would improve the mini-Perl's reputation; full Perl's reputation would remain unaffected.

A lot of people say that "TIMTOWTDI is the main reason for Perl's write-only reputation", but I'm going to humbly disagree here. Instead, I argue that Perl's TIMTOWTDI- and 0222-ness instead both follow from something else: a huge language with lots of syntax that both mixes programming paradigms and manages to be unique at the same time. Here're a few examples of what I mean (please feel free to correct me or my examples if I'm or they're wrong!):

• A quick script I wrote shows that perlfunc contains 217 entries or so, with 331 usages or so. See also szabgab's Perl index. That's a lot of functions!
• Many people find the default/implicit variables $_ and @_ confusing. It seems to me that this idea is largely unique to Perl and leads to such problems as "why does ord() mean ord $_ but srand() does not mean srand $_?" or "why can't I omit @_ from map?" The lack of formal parameters (yes, I know they exist now, but most people don't use them) leads to things like sub mult{$_[0]*$_[1]}.
• Context! New programmers often have difficulty adjusting to the fact that functions return different values depending on how you call them. To some people, this seems like a violation of the "you can't know why I'm calling you, just do your job" abstraction for functions.
• Two words: regular expressions. Although they are perhaps one of the most useful things in Perl, period, they do have a lot of syntax associated with them. Consider the number of modifiers m//cgimosx; for readability, notice that spaces are interpreted literally unless the /x modifier is added. However, other languages are trying to import Perl's regexps (see Java) or their own variant (see C++ (Boost)). See also the line noise comment later.
• There are some logical things in Perl that are a little foreign to, say, C programmers. These include unless( FOO ){ BAR } or the BAR if/unless FOO variants of the same. But these too are sometimes unusual: in the script I mentioned above, I wrote print $1 if /^\s{7}(\S+)/'; what is the $1 here? You have to look ahead to find out. More reasonable things that take some time to get used to include allowing trailing commas in (1,2,3,) or allowing lacking ending semicolons in sub f{my $x = shift; $x**$x}, the <FH> operator, or an alternation operator || that actually returns the value that was true (so $var ||= $default or $var //= $default works as it should)
• Perl is nice enough to let you avoid parentheses wherever possible. This is great, but sometimes it's a little confusing, in particular when the "if it looks like a duck function, it's a function" rule gets in the way of an honest print (2+2), "\n".
• There are a lot of functional programming paradigms in Perl, an otherwise mostly procedural language, that are also foreign to C programmers. These include fun things like map, but also more complicated things like closures. Also, Perl manages to have both lexical and dynamic variables; compare Scheme, which has only lexical variables.
• Perl allows you to avoid a lot of spaces, allowing smushing of function and variables (func$var) and such.
• I think the most common Perl insult is that "it looks like noise". What contributes to this perception? I think it was the design philosophy of "Huffman coding" --- commonly occuring things are short. However, to make this practical, the "alphabet" was extended: the pattern m'[$@%#\\<>~]' fails on most lines of code in other languages. In addition, some things were overloaded (like {..} for hashes and functions). Regular expressions usually do not help, because they're pretty well Huffman-coded (although I think Perl 6's pattern matching is a step in the direction of both better coding and comprehension). Finally, things like $#$_ just baffle new programmers, I think (disclaimer: I think that Zaxo's response is good there and not confusing; I am just commenting abstractly). Note also the special variables, like $/ or $".
• I'm not even going into obfuscation. Notice that most obfuscated C code uses the preprocessor heavily.

This isn't a full analysis, but it's a start. What I'm saying is that TIMTOWTDI comes from some of the above (especially the function programming paradigms and regexes), but that the inherent nature of the above also causes write-only-ness. That is, they have a common cause, and not that TIMTOWTDI causes write-only-ness.

Disclaimer: By the way, don't get me wrong ... I love all of these things about Perl, particularly one liners and the interaction with the Unix pipe philosophy. I, however, have talked with many people who don't like Perl since I usually mention that it's my favorite language.

Update: Spelling, formatting, and such.

All those things are true.

$_ and @_ are confusing largely because there's no single piece of documentation which lists all the functions that assume $_, which functions will implictly set it, and so forth.

I'd add: perl is inconsistant. $_ acts like an alias inside a foreach, but doesn't have the same side effects outside the loop. @_ means @ARGV, or the parameter list, depending on whether you're in the main program body or not.

Perl lets you do things in inconsistant ways: this is part of the TIMTOWTDI design. Once you let there be multiple ways to do it (inconsistant design, that accomodates multiple ways to do the same thing), you don't worry about a few more inconsistancies thrown in here and there, even if they're confusing to a novice.

Try explaining the word, let alone the perl implementation of the term "autovivification", and watch the eyes glaze over really fast...

The lack of formal parameters (yes, I know they exist now, but most people don't use them) leads to things like sub mult{$_[0]*$_1}.

Huh?!? Do they exist now? Aren't you talking Perl6 by any chance? If so, then I wouldn't say "they exist now"...

Incidentally one of the things I like about Perl (but then I just love it to the bone in any case!) is how its simple parameter passing mechanism can be put to mimic so many different styles, e.g. by reference, by value, named.

Update: Incidentally I recommend that when you change the subject of a node within a thread you include the previous one. I've been bit in the neck by this myself. See my own post at Q re nodes' subjects.

Larry Wall once said (I think it was at Linux World 1999):

The very fact that it's possible to write messy programs in
Perl is also what makes it possible to write programs that are
cleaner in Perl than they could ever be in a language that
attempts to enforce cleanliness.
[download]

Perl is such a powerful language that it easily can be misused. I committed several crimes in my first days of Perl programming because I didn't know better. But in the meantime the layout and readability of my code became very important for me (especially since I'm very forgetful, I have to do something to be able to understand my code even after longer holidays or the like ;-) ).

I think part of the "problem" is that some people fail to understand the difference between the ability to read a single line of a program and to be able to read the program itself. It's true that a single random line of a Visual Basic program is easier to read and understand than a single random line of a Perl one. The problem that they fail to see is that there's about fivety times more lines in the VB program than there would be in a Perl one with the same functionality. So they know what each single line does, but once they tried to understand the functions they would quickly find out that the complexity is still there. It just wasn't aparent from the looks of the lines.

I use Perl for admin functions and data processing, and PHP for most of my web pages. I often generate PHP from Perl, or write a rough draft of something in Perl and then rewrite in PHP once I have a good lock on what I'm trying to do.

I'd like to repose your question, but with a broader scope to encompass a lot of the discussion that's taken place on this thread and a spin on it for some perspective:

Let's have a look at The Win32 Shootout so we have a reference point. My version of the question would be: Is there a relationship between readability & performance? (Be it negative or otherwise)

I ask the question because I think it's fair - if you have to trade readability for anything then performance should be on the top of the list.

I'll start by saying that it's a very difficult thing to measure because 'readability' is subjective. We all have our own experiences & to some people sweetened/verbose code is more familiar while to others it clutters up the algorthyms and makes it harder to see the Big Picture.

But even so, is there a trend? It might seem intuitive that the most cryptic optimizations are usually those that perform best, but is it actually so?

I realize that performance isn't the key quality that we're measuring here. But in my experiece there's a negative relationship between compatability & efficiency (the classic example is XML vs. binary data) and so I'm wondering if there's a relationship to readability. Any thoughts? I mean fundamentally there's a reason why we all don't write in assembler, right?