How did Perl gain a reputation for being a write-only language?

Question

How did Perl gain a reputation (deserved, undeserved, or used to be deserved, no longer so) of being a "write only language"?

Was it

• The syntax of the language
• Specific features that were available in the language
• Specific features not being available in the language (or at least old versions of it)
• The kind of tasks Perl was being used for
• The kind of people who use Perl (people who aren't full-time programmers)
• Criticism from people committed to another language
• Something else?

Background: I'd like to know if some aspects that gave Perl the reputation of being write-only also apply to other languages (specifically ruby).

Disclaimer: I recognise that Perl doesn't force people to do write-only code (can any language?), and that you can write bad code in any language.

Edit: If reasonable, describe aspects of the language that make it write-only-prone in a way that non-Perl programmers can understand.

Answer 1

I don't think it really had anything to do with Perl, but the accident of history that Perl became popular in the 1990s.

When the big Internet boom was going on, anyone with a pulse could get a job as a programmer (or a CEO, visionary, whatever). Perl, having a low initial learning curve, was used by a lot of people who didn't really know any more about programming than the very basic Perl they scrounged from examples. They didn't really care about quality or learning programming, but were hoping to cash out of some big internet success. It was the Wild West of programming, and there weren't enough experienced team leaders (if any in most places) to do anything about it. The code they pumped out was horrible, but everything lives forever on the internet. More people copied the crappy examples they saw. A lot of people relied on genetic programming accidently: cutting, pasting, and adjusting until things worked without understanding any of it.

And, at the start of the internet boom, there wasn't any software to do the sorts of things that people wanted to do on their web pages. If they found a script from some 15 year old, they just used it. They'd get some other kid to make some changes, and so on. I'm not making this up, and I'm thinking about very real people whom I won't shame publicly. That stuff got passed around liberally. People built entire business plans around 100 line Perl scripts that they found on the Net, didn't understand, and never intended to rewrite. Some of us have the scars for un-fubaring those situations when they hit the scalability wall (no, you can't have 40,000 subscribers and fork a process for each of them every five minutes).

Perl also has the benefit that it's partially designed to be very accessible. "Regular " people can get quite a bit done with just the stuff in Learning Perl, which is only the very basics and only about 400 pages. Since this part of the audience has very little background with programming, they often come up with interesting paths to their problems. They forget why they cobbled so much weird junk together, but they don't want to change any of it because they won't know how to fix it.

Mind you, this has nothing to do with smarts or intelligence. It's mostly just an experience problem. "Baby Perl" is very easy to use for the inexperienced, or "accidental" programmer. These people typically care more about other tasks than programming, so they don't really have iterative delvelopment and improvement. When they get close to a solution, no matter how ugly, they tend to stop. Unfortunately, that's a lot of the code that the public sees.

Ruby has the advantage of seeing its boom after the dot.bomb, and it started off with a community that mostly knew good programming techniques already and just wanted a better language. I don't think Ruby has had the same problems for that reason. People weren't rushing to mine the internet gold, so Ruby's progress and community evolution has been much more sane. It's not an accident that 37 Signals loves both Ruby and beautiful design. :)

Answer 2

A couple of things have contributed to the Perl's write only reputation.
1. As brian noted, popularity in the early dotcom boom.
2. Perl is very flexible and expressive. It gives you more than enough room to hang yourself.
3. Perl has some very unconventional features (sigils, context, list based argument passing, and dynamic scoping, and first class regexes, to name a few) that make it behave differently from other programming languages.
4. Perl is a big, deep language. While you can start toddling around on day one, really understanding the deep details takes time and experience.
5. Backwards compatibility with Perl 4 adds some unusual features.
6. Many bad tutorials exist that promulgate bad or outdated techniques.

Combine all these things and you get a lot of bad code.

The last few years have seen major efforts by the Perl community to emphasize good technique. Tools like Perl::Critic and perltidy help a lot.

I see posts on SO where people expect Perl to act like a shell scripting language. They randomly include files (something that was common under Perl 4), and shell out subprocesses when built-in functions would readily handle the tasks at hand. These posts typically come from people new to Perl, so I surmise that they are somehow finding books or tutorials written in the early to mid-90s that show this stuff.

I've seen some monstrously bad Perl. But I have also seen amazing, stunningly elegant code. The expressiveness that lets a fool soil his bedding also allows wiser heads to write better, cleaner code.

Answer 3

All the one-liners that people used to write to automate things! The one-off scripts. The notion of TMTOWTDI.

All those things contribute to perl's line-noise reputation.

Answer 4

For me, the main reason for Perl being write-only is an enormous amount of ways to do simple things while lacking the most straightforward.

When you read code, you read idioms, and you juxtapose the patterns you see with patterns that are in your head. But if there's a lot of ways to do simple things (say, finding an index of an element in an array) you'll have to think more when you're reading, or keep more patterns in your mind. And these patterns tend to quickly become insanely tricky pieces of code.

There's a question full of solutions how to find an element in an array; some answers link to perlfaq and Perlmonks nodes. Check the number of variants to see what I'm talking about.

Whereas 100% of Ruby users will write array.index(x).

Some people say that they're surprised that the Ruby code they write to solve simple problems is very similar to that others write to solve them. For Perl, each programmer has its own set of favorite idioms (maybe even varying throughout a single script), and codes things differently. Perhaps, that's the reason.

Answer 5

Perl is heavily influenced by natural languages. There are multiple ways to express code in Perl because there are multiple ways to express things in English.

You can write good English, or you can write bad English. Both get the message across, the former takes more effort on your part - the latter requires more effort on the part of the reader.

Perl allows you to get the job done without any thought for readability. This can be a boon when writing one-liners or one-off scripts. It also allows you to write idiomatic, easily understood code. (If you can get past the sigils, that is.) Perl can scale from one-liners up to "enterprise", depending on how you use it.

Back in the dot com boom a lot of people wrote a lot of bad Perl. But you can write bad code in any language. Perl just makes it easier.