Take the 2-minute tour ×

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.

share|improve this question

closed as not constructive by Bill the Lizard Apr 12 '12 at 12:21


You don't "read Perl". You read Perl code written by someone. –  brian d foy Apr 24 '10 at 0:58
@Mike: that's the exact sort of prejudice that this question is attempting to shine a light on, so repeating it here isn't very useful. Flagging as offensive. –  Ether Apr 24 '10 at 1:03
@brian: One does not simply ... read Perl code! (Sorry, couldn't resist the snowclone) –  Andrew Grimm Apr 24 '10 at 1:14
@Mike: as an analogy: someone recently asked the question "Why are women programmers not valued as highly as men?" -- consider if the first response was "Have you seen the average woman try to code?" <-- see, this is offensive. –  Ether Apr 24 '10 at 1:17
@Ether - Your example is offensive because it's insulting a person or a class of people. Perl isn't sentient, and thus can't be offended by being insulted. (Lisp is, and will definitely hold a grudge if insulted.) If the statement said "Perl programmers can't write readable code." then it would be offensive (no matter how true it is) because it's insulting a group of people (and it's still such a minor offense that it still probably wouldn't warrant being flagged as "Offensive"). –  Nate Apr 24 '10 at 2:45

8 Answers 8

up vote 34 down vote accepted

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.

share|improve this answer
Is there any easy way to avoid bad or outdated tutorials? –  Andrew Grimm Apr 24 '10 at 9:52
@Andrew: Probably the best shibboleth is to check for the lines use strict; use warnings;. If the tutorial doesn't use them (or at least state a reason for not using them), then it's extremely unlikely to be one which promotes good practices. Spelling it "PERL" (in all caps) is also widely considered a bad sign, but I consider that more of a "not involved in the Perl community" flag than necessarily "doesn't know what he's talking about". –  Dave Sherohman Apr 24 '10 at 11:36
@Andrew, to Dave's suggestion for strict and warnings, look for 3 argument open on lexical variables. The sad thing is that a newbie trying to learn doesn't know to look for these things. –  daotoad Apr 25 '10 at 20:50
As a small addendum, I've found some of the best ways to write good Perl is to seek out what people consider bad Perl, like this. Keep PBP around. perlcritic everything. You may not agree 100% with all prescriptions, but I've been floored by the amount of bad advice that's obvious when reading beginner code. Even perldoc isn't safe (try perldoc perlopentut for two-argument opens to global variables)! Good Perl is not obvious, and without someone slapping my hand I would have found it difficult to develop good habits. –  brymck Oct 28 '13 at 15:41

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 development 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. :)

share|improve this answer
Very good points. If PHP was as old as Perl, it would have gotten the same rep, as it is used today in a very similar way to how Perl was in the 90s. –  Ether Apr 24 '10 at 1:05
How often do we see assertions like "CGI is obsolete--you shouldn't use it 'cause Perl looks line-noise and is too slow." –  daotoad Apr 24 '10 at 1:18
Actually, Ruby has the same maintainability problems that 1996 Perl did. Programing communities, when confronted with popularity and a lot of new programmers at the same time, tend to make mistakes. Perl learned from those mistakes; it's very likely that you can use any two CPAN modules in the same program. Ruby, on the other hand, has not learned from their mistakes, and monkey patching often precludes using two modules in the same program. Rails is an especially bad example. –  jrockway Apr 24 '10 at 1:31
I don't think Ruby was making the monkeypatching problem because of newbies. I've listened to more than a couple of experienced Ruby programmers talk about how good monkeypatching is. –  brian d foy Apr 24 '10 at 1:33
I have a chapter about monkeypatching in Mastering Perl. It's a dynamic language, so of course you can do that. :) –  brian d foy Apr 24 '10 at 2:01

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.

share|improve this answer
He did give an example. –  brian d foy Apr 24 '10 at 1:42
I think that's a bad example. Experienced Perl programmers will use List::MoreUtils::firstidx because that's the best tool for the job - most of the other answers cover the case where there duplicate values in the array. Similarly, Ruby programmers will use Array#index. Yes, Ruby has the function in core. On the other hand, I've had to hand-roll Ruby functions like shuffle, sum, mean and permute (usually monkeypatching Array) whereas Perl offers namespaced export of these functions via CPAN. –  rjh Apr 24 '10 at 11:28
The linked question has responses to several different implementations depending on the needs of the user. For example, some answers show using firstidx to find the first match in an array. Others show how to index the entire array to handle multiple lookups. Some examples explain how to handle duplicated items in the array. I doubt all Ruby programmers would have answered with Array#index since I find it hard to believe that no Ruby programmer would see the possible need to make multiple queries without repeated traversing the array. –  daotoad Apr 26 '10 at 6:24
Linking to the FAQ is reasonable, but it's friendly to excerpt and expand on the FAQ article. OTOH, linking to a golf contest isn't exactly reasonable. Golf contests use only the simple metric of code length to measure quality (although devious abuse of obscure features is also appreciated). IMO, it's not a good idea to send a newbie to a golf contest for help. You can learn a lot from well golfed code. But you certainly don't want to emulate the style. The difference be golf and real code must be made clear to newbies. If it's not clear that code golf is a game, then we have a problem. –  daotoad Apr 26 '10 at 6:31
In any case, the example is well chosen. I have been scripting in Perl for 17 years now, and just yesterday I made another scan in the manuals to find a function that tells you whether an element occurs in a list. It's not exactly obvious that you'd have to look for List::MoreUtils, and install that first, and tell everybody who wants to use the script to install it, before you can use one. The idioms I use myself to do this (with grep and map) aren't obvious to most programmers. –  reinierpost Mar 9 '11 at 9:52

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.

share|improve this answer

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.

share|improve this answer
What aspects of Perl make it more prone to one-liners? –  Andrew Grimm Apr 25 '10 at 23:10
Not prone, but suitable. The amount of things that can be compactly expressed in a single line encourages this. (Which isn't necessarily a bad thing) –  Alex Budovski Apr 26 '10 at 1:50
@Andrew, Perl has many features to make one-liners easy. Consider perl -ape '$_ = "@F[1,5]\n"' somefile.log anotherfile.log. If you don't understand -a (autosplit), -p (assumed while with print), variable interpolation and array slices, this code isn't going make any sense. It just looks like weird magic. If you do understand Perl, you have a very powerful tool for ad hoc tasks. What is important is that a developer develop a sense of propriety--knowing what techniques are acceptable in a given situation. Abuse these tools at your peril. Use these tools well and gain productivity. –  daotoad Apr 26 '10 at 6:52
Yes, exactly. The perlrun[1] manpage does a pretty good job of describing these. Remember that Perl was originally designed for getting stuff done, fast. Being able to write a chunk of code that was going to be exactly the same as it was the last time via a single character is a huge gain in expressivity - just like a single character in Chinese can express a complex concept. For someone who doesn't know it, Chinese is also pretty opaque. (perldoc.perl.org/perlrun.html) –  Joe McMahon May 4 '10 at 3:46
FWIW, Ruby stole most of Perl's program wrapper cmdline switches. @daotoad's oneliner is pretty similar in ruby: ruby -ape '$_ = "#{$F.values_at(1,5).join(" ")}\n" somefile.log anotherfile.log A bit longer because ruby's default interpolation of arrays into strings is different. –  dbenhur Nov 27 '12 at 23:26

One more reason - people don't like the '$' glyph - it does not have the same polish of hundreds of years of typesetting as all the other latin characters - and '$' is what frequently forms the first impression of Perl. After this first dislike people will invent any reason to justify it.

share|improve this answer
Exactly, same goes for PHP –  Milind R Feb 28 at 6:50
That's true. Just getting into Perl, this is what put me off at first. But I found many, many other things by now that are not just justifications of that initial dislike. Perl is basically just a big mess, compared to any well designed language. You can get stuff done, you can do it quite beautifully, you can express your inner nerd like in no other language. But it is still a mess. –  jackthehipster Aug 21 at 10:03

I would add another point worth considering: Regular Expression Use.

In my experience, a lot of people who complain about Perl syntax aren't actually complaining about Perl, they're complaining about regular expressions. However, many of them, particularly those coming from the compiled code world, aren't familiar enough with regular expressions to understand the difference.

Perl, with its strong history of text processing, coupled with its ease of use and awesome integration with regular expressions, makes regular expressions a natural fit for a lot of solutions.

share|improve this answer

Early Perl versions (1-4) were designed to work in a particular niche -- to fit in on unix where bourne shell, awk, sed and find were traditionally used, but couldn't quite handle the task. Perl has a lot of features designed to make this use case easy -- magic variables, dynamic scope, autosplit mode, etc.

Modern Perl eschews many of these, in favor of structures provided for programming in the large -- packages, modules, lexical scope, etc. But there are lots of example out there that feature and use the older features, leading people to think of that as Perl.

share|improve this answer
