Why Hate Perl

See WhyLovePerl for opposing viewpoints.
Some believe that a reason to hate Perl is that there are always one or more modules missing. However, TheCpan along with the CPAN module (and its putative replacement, CPANPLUS, which does everything CPAN.pm does and more besides) make that a non-issue. One of the best bits about Perl is the simplistic ease of maintaining the packages:
 perl -MCPAN -e shell
 install Some::Module
LessIsMore !! use cpanminus (http://search.cpan.org/perldoc?App::cpanminus) !!
 cpanm Some::Module
Ugh, this sounds like it belongs in the WhyLovePerl page.
I hate PerlLanguage extra due to the critical mass of enablers around LarryWall who actually like its horrid syntax. -- PhlIp

Also because of the constant gushing hero worship at the feet of LarryWall. His sense of humor is so obvious.

(But some of us like LarryWall but still hate PerlLanguage. JasonGrossman)
Wrote my first Perl program today. And I can see why the kind of people that find tinkering around with network configurations all day would enjoy it. Using prefixes like $, @ and % on identifiers isn't a good way to express your type system. But it is cute, it is cool, in that down-in-the-bowels-of the system way that some people in the industry like.

And it is also because parser variable interpolation is cleaner than adding strings:
 my $world="Earth"; print "hello $world\n";
 String world = "Earth"; System.out.println("Hello " + world + "\n");
However, this particular malady has been addressed in Java 1.5, so you can now do things like:
 String world = "Earth"; System.out.format("Hello %s\n", world);
Uh ... the malady has not been addressed with that particular archaism ...

There are people who thrive on learning random facts by brute force, and for them $_ and <>' are perfectly clear, even intuitive. These people are very useful to have around, sometimes. But I no more want to use the tools that those folks get off on to write my software than I would want to make up my own wet collodion plates to do photography. It's not masochism that makes people think that this kind of thing is good, and it's not lack of thought, either, though it kind of looks like it. Maybe there isn't even a word for it. But this way of thinking about software, what it's for, and how to write it, that Perl seems to represent is not something I even want to know exists, never mind get involved in. It's creepy.

Consider this: how could one think ContextSensitivity a big win unless one also thought that it's better for the programmer to keep a bunch of state about the program in your head, including a rules about the interpreter's default behaviour, than to type a few $_s. Do you think this way? Then Perl is for you. Want to devote most of your mental effort to your problem, rather then your technology? Then Perl is not for you. Clearly, the elegant iconography of code, a practice that extends far back in the history of mathematics, and championed by the likes of Leibniz, is completely lost on folks who make such arguments. The iconography of perl takes advantage of the signifying capability of the ASCII character set, by assigning simple mnemonics to each prefix - e.g. $ = value (as in "show me the money"), @ = array (as in there is a little a in there), % = hash (as in a pair of little round thingies), etc. It takes a second to learn and simplifies things immensely, where other languages force a roll-your-own Hungarian syntax that is both ugly and unscannable, since you actually have to read a variable's name to determine what the heck it is. Languages such as Java and Python remake the mistake of BASIC, which falsely assumes that spelling things out makes things simpler. Not! The simplicity of language lies in its morphology, syntax, and pragmatic structure. Larry, a linguist, knows this. (It is also HungarianNotation, which is just a smidgen shy of being universally rejected by any programmer with even 3 days of coding experience. --SamuelFalvo?)

See TheProblemWithSigils.

I use Perl. Mostly, I like Perl. But there are some things that Perl does that I cannot stand.

The syntax. I can live with $, @ and even %. But please, not the references. Not the anonymous references to an array of hashes which make less sense than the ThreeStarProgrammers on h4X0red crack.

$, @ and % aren't just syntax, they're semantics as well. Every time you access a variable, you're doing a cast.

The type safety. Call me crazy, but I'd like to define a variable as a specific type without having to assign it.

 *You are crazy. The very existence of references and their ubiquity is a pretty clear indication that your type safety is only virtual. Why do all the work casting things back and forth? The computer is faster and better at keeping track of type anyway.

The functions calls. I realized they've improved and now you don't need & any more. But perl has no clear means for exception handling, no good returns, the parameter handling sucks (try passing two or more arrays in!), and even when you use a prototype, it's done in the eclectic Perl fashion ($$%@) is four parameters, all of which are without names. Whee.

passing two or more arrays - I just as much or more often want to pass a flattened array to a function that expects multiple arguments. I like how easy that is in PerlLanguage. A backslash to pass by reference when I want to do that is no big deal. You can't have it both ways (default behavior, that is). I know RubyLanguage prefixes a "*" when you want to flatten a list. I don't care which way it is. It's going to be inconvenient whenever you want to do the thing your language doesn't do by default.
Of course, there's always the HaskellLanguage way: "function list1 list2" for passing two lists, and to pass two lists flattenend "function (list1 ++ list2)". I don't see how automatically flattening the lists is the preferred default. It is not the obvious or naturally expected behavior to anyone but a PerlLanguage weanie.

exception handling = die; returns = return scalar or list (and you caan find out what you want if you really want to (but you shouldn't)); parameter handling - lists do get flattened, but typeless languages have the amazing advantage of not requiring stupid things like C++ templates or the java generic language package; prototypes are for automatic input conversion, not. -- JeffBay

Perl doesn't mess up lists in method parameters because it's typeless. It messes up lists in method parameters because Wall & co screwed up when they defined that part of the language. Check out RubyLanguage for an example of avoiding the braindead Java collection classes while still making it painless to pass collections as method arguments.

To JeffBay: Surely the comparison of 'die' to real exception handling is a joke? Also, nobody is denying the benefits of typeless languages: the TclLanguage is perhaps even less typed than Perl (lists also being strings) and the PythonLanguage also is loosely typed and yet there is far less messing around with parameters and magic than with Perl.

See ExceptionHandlingInPerl

You surely made a mistake somewhere, the PythonLanguage is extremely strongly typed. It's typing being dynamic and late-binding doesn't make it loosely/weakly typed.

The imports. I realize that Perl has a wide library of utilities. But have you tried packaging these things? Can you figure out from context what these things do, without looking at the docs? Are they self-documenting? Do the parameter names make sense? No, no, no and no. The whole thing is hacked up from the bottom and held together with CPAN and perldoc.

Have I tried packaging them? Yes. It's a snap. 20 seconds with H2XS and you have a blank package, populate it with code, type 'make dist', job done. How easy can it be?

And as for the 'can you figure out what they do without looking at the docs' - Jeez, I know that reading documentation is alien to some people, but it is there for a purpose you know!... And even then. if you can't work out that a module called 'XML::Parse::Simple' is a simple XML parser, then there is no hope for you.

I concur with the above criticisms, especially the lack of real exception handling (and suggesting die is a bad joke made all the worse by the fact that it's a serious suggestion and even a widely-used practice) and really especially the crippling difficulty of passing multiple arrays to a subroutine. This latter fault is, i think, actually a symptom of a general failure to make arrays work sensibly - rather than treating them as first-class objects, it's almost like the interpreter just rewrites them as a sequence of scalars and pretends they never existed. Consequently, passing two arrays to a subroutine is a hopeless case, and passing in or returning an array (or even moving it from one variable to another) actually makes a copy (if I wanted a copy, I'd ask for a bloody copy; now tell me how I'm going to get this data out of my subroutine without using the return value or a global!). Of course, all these problems can be overcome by using references, but in more considered languages, like Java and Python, this is simply the normal behaviour of variables, and things work without half a dozen extra characters. And while we're at it, why do LarryWall and company think that every problem can be solved just by throwing syntax at it? I hate perl. -- TomAnderson

Can you clarify why you think the die/eval exception handling model in Perl is so bad? It does everything that I need exceptions for.

JUST PASS BY REFERENCE! RealProgrammers have always passed by reference anyway, it's only when I read this I even realized that passing multiple arrays would be a problem without references. Since I naturally create arrays and hashes as references in the first place - eg my ($foo) = {}; - then I never even worry about the problem. Just use references and quit whining.

No, JUST USE A LANGUAGE WHICH GETS IT RIGHT! Real languages have always passed by reference anyway. You are, of course, absolutely right that references are the right solution. So why is there a non-reference option? Why am I forced to ignore the 'normal' mode of variable use, forget that I ever so much as saw an @, and go around writing $foo->[0] to get at the contents of my arrays? Idiotic! Just use python and quit crying. I don't understand this last bit. The Perl critic seems to be the one who is crying and needs a different language. Idiotic indeed.

Oh, and while we're at it, let's not forget that you're not allowed:
 if ($foo) doSomething() ;
Because you have to have a block there! And before you get all "doSomething() if $foo" on me - shouldn't there be more than one way to do it? Ideally, including at least one way that's consistent with the multi-line version?

That's better? Rather than having a slight variation between one-item and N-item cases, now when you want to add doSomethingElse() you now need to...

All this in addition to adding the "{" and "}" that you would have to do anyway. Just brilliant. Id like to add that Awk does it best:
  if(foo) doSomething
note the lack of ; at the end of a line. Most times a newline is a proxy for the end of statement, so doing it the other way a round (using \ to continue, in rare cases) is best.

How about
 $foo and doSomething() ;
then? -- ch

 sub astonishingly_handle_two_arrays_like_only_good_languages_can_do (\@\@) { 
     my ( $array_ref1, $array_ref2 ) = @_;
     return magic( ... );


astonishingly_handle_two_arrays_like_only_good_languages_can_do( @array1, @array2 );
Kind of makes me wonder how much people "know" about Perl that just is not so.
Perl modules have to end in a true statement, which is almost always the statement
which you will see at the end of EVERY Perl module ever. This looks really stupid. Hey, what's this no-op 1 doing here? I'm gonna remove it. Oops, your module doesn't load.
And hey, what about the fact that filehandles live in a completely separate namespace to scalars, so you can't put them in arrays or pass them to subroutines? What's that? You can wrap them in an anonymous typeglob? Great! That's an ideal, elegant and not at all mind-numbingly kludged solution to the problem! As a comment below mentions, starting with Perl 5.6, if you want the filehandle in a scalar, just do it: 'open(my $fh, $filename);' The filehandle is now in $fh. Wasn't that easy? :-)

Surely there's already a PerlBugs?/BadPerlFeatures?/PerlMisfeatures?/WhatsWrongWithPerl? page on wiki? After all, this is now a holy war of positively old testament ancientness.

That's been fixed for just over 10 years now.
That's a bit too balanced for a page called WhyHate anything. So how about this: Perl is ideally suited for the kind of pond-life that get IT a bad name.

People who genuinely prefer Perl to Python or Ruby are sick, and should be put down, for the benefit of themselves and humanity. NB that's 'put down' in the British sense.
I tried using ppm under Windows 98. It fell over and died... so I went back to perl Makefile.PL - and it died with an illegal instruction. Everything is possible, but not much is reliable. -- Sheesh, what did you expect from something brain-dead like Windows98? You're lucky to get a port of Perl that works there at all. It wasn't that long ago that the main (only?) port of Perl for win32 was Gurusamy Sarathy's personal project. (I think he works for Activestate now.)(Feel free to delete this comment if it's out-of-place. (You would anyway, right?)) -- DavidWall
The other day, I was looking at some perl code, and saw this line:
	my $fh = do {local(*FH);};
Do I really have to say anything else?

Depends. Do you want me to understand what you are on about?

OK. How about: What the $%^&(^#@ is that?

It's pretty much equivalent to using a Vector in Java. i.e., deprecated. -- JeffBay

-- DirckBlaskey

What's $%^&(^#@ ? Well it's not a perl variable name (...yet... wait till Perl 7) -- RomanStawski?

For the curious, do {local(*FH)} creates a local typeglob named FH and immediately takes it out of scope (its scope is just the do block) and returns the now anonymous typeglob. Assign that to a variable and you can now open a file on it, etc.

As of Perl 5.6 you can open a file on a variable without assigning a typeglob to it first, so this hack is no longer needed. And, of course, Perl 6 will get rid of typeglobs entirely.

But let me ask you, now that you know what it does, do you think more or less of it?

-- BenTilly

More or less? I try not to think about it. I had managed to figure out what it was, sort of, but that didn't lessen my incredulity. It's just a magic incantation to placate the interpreter. Perl is full of magic incantations. The more magic in a language, the harder is is to learn and remember. It took until version 5.6 for this to go away?
It is often extraordinarily difficult to read and maintain Perl programs.

This is generally thought by those who never bothered really learning it, and whose only experience of Perl is trying to debug garbage written by other amateurs. I've seen plenty of code in other languages that would, to me, be "write-only". Then again, I never learnt those languages. BadCodeCanBeWrittenInAnyLanguage.

There is a lot of truth to that, but I posit that Perl makes it easy to write unreadable code.

    *Comment: It's almost like unreadable/maintainable code was woven into the design of Perl. use strict; use warnings; 'nuff said. 

If MicroSoft had invented Perl, we would have had more anti-Perl pages than anti-VB pages.

Be thankful that MicroSoft didn't invent Perl. If they had, the documentation would be so bad that nobody would ever be able to figure out how to use it. On the other hand, is that really a bad thing? :)
I find Perl good for simple things; even simple web forms. Once the project gets sufficently large (enough where there are more than two developers), using perl can be a major development risk, in my opinion, just due to the non-structured, nearly unreadable code.... (developing 'common' Perl modules amongst a team of ten developers can be an exercise in near torture...) -- ChadThompson

I worked on (well, managed development for, with a litte bit of working on) an 80,000 line Perl web application, written by competent programmers. It was well structured, and a pleasure to work with. We could make and test extensions very quickly. Perl gets a bad rap because a lot of people hack together CGI scripts in ways that aren't clean and won't scale. Apply the same discipline you would when working on a larger C++ or Java application, and many of these perceived problems go away. -- DaveSmith

I`m sure you can develop good software in perl using some discipline. It`s probably easier in a more sensible language - like APL or LOGO or SNOBOL or PROLOG or Postscript or... -- DirckBlaskey
First a perfectly absurd example. The following line is not a no-op, and knowing what it does can be very important when writing parsing logic in Perl:
	pos($foo) = pos($foo);
This resets a flag on $foo. That it does this is documented. To the best of my knowledge, it is mentioned exactly once in the documentation, but it is accurately described there. To learn that it sets a flag and what this flag does you have to read http://www.ayni.com/perldoc/perl5.8.0/pod/perlre.html#Repeated-patterns-matching-zero-length-substring and not miss the implications of the last paragraph. Of course, the few people who got that far in perlre without their eyes glazing over completely are unlikely to get past the first sentence of that section. (Follow the link to see why not!)

Now for a bigger problem. Perl's scoping rules are so baroque that one of the most widely quoted tutorials on the language is named Coping with Scoping (and is found at http://perl.plover.com/FAQs/Namespaces.html). The underlying problem is that originally the language was dynamically scoped. Sometimes the dynamic scoping was explicit, sometimes not. Perl 5 introduced a lexical scoping system which only some things worked with. Over releases of Perl, what will work with lexical scoping has increased. See the do{local(*FH)} example for something which didn't work but now does. So Perl has 2 scoping systems which do not cooperate, and things that you would want to be lexically scoped (like $_ - which is implicitly used a lot and is always in package main) almost invariably are dynamically scoped instead.

This tutorial was, of course, written before the "our" operator was added. That operator provides lexically scoped access to a global variable. I have commented on why I think badly of this at http://www.perlmonks.org/index.pl?node_id=48379. But anyone who remembers, for instance, Fortran's common blocks shouldn't need it explained...

-- BenTilly
I could go on at great length about the bizarre and ugly syntax of perl, the myriad boobytraps that penalize clarity and reward obfuscation, the general frustration and head-banging that the language causes... but rather than reiterate other people's points, let me point out two articles of perl dogma that seem to form the basis of the whole perl mindset:

These are simply asserted as articles of faith that you may not question without invoking the wrath of the perl gods... but common sense and everyday experience tell you they are just plain wrong. Proceeding from a wrong premise, it's no wonder that the language has developed into a Byzantine monstrosity and is beyond hope IMHO.
In RubyLanguage or SmalltalkLanguage, everything's an object. In PerlLanguage, everything's a string. Sort of.

But Perl permits ObjectOrientedProgramming! You just write @%$#&.

Bless you. -- PhlIp
I'm learning Perl from the O'Reilly book "ProgrammingPerl". In the first section on RegularExpressions, there's sample code for finding all the "http"'s in a file and printing them:
	while ($line = <FILE>) {
	  if ($line =~ /http:/) {
		  print $line;
That seems reasonable. Below this is another example that does the same thing, prefaced by "so a veteran Perl programmer would likely write the last example as:"
	while (<FILE>) {
	  print if /http:/;
I thought to myself, "These authors really don't understand how veteran programmers think. Veteran programmers avoid tricks so they don't have to repeatedly explain them to junior programmers." Then I looked on the cover and saw that Larry Wall was one of the authors. Suddenly, it all made sense: Perl is the perfect language for writing code that only one person will ever look at.

-- EricHodges

PerlGolf: print grep/http/,<FILE>;

That's veteran for a rather small version of veteran. A couple of weeks of perl will have you writing like that. The main complaint against perl seems to be - perl does things that I've never seen before. Well, yes.

It also does things that just plain don't need doing. Some complaints from one Perl vet:

	package ExampleClass;

sub new { my $proto = shift; my $class = ref($proto) || $proto; # Preceding line is not necessary or common. --JesseMillikan

my $self = bless {}, $class; # You forgot return bless { @_ }, $class

return $self; }
Chinese is so hard for use non-Chinese speakers to maintain! I'll start my page on Why Hate Chinese...

WHY? Why do I have to type this all the time? Why not a standard high level construct to do this? This is a language which values terseness?

You can choose not to write that EVER again, by writing:
        sub UNIVERSAL::new {
	  my $proto = shift;
          return bless { @_ }, $proto;
Then all you ever have to do is type
  use Module::Where::I::Put::UNIVERSAL::new;

my $obj = NotAClassIKnow->new( thing => 1 );
Of course the really weird thing is that you could have code that uses that and code that _doesn't_

You want terse? How about:
 package ExampleClass;
 sub new { bless {}, shift } # No 'ref($proto) || $proto' crud (i.e., CargoCult constructor code).
I think when he said terse he meant is in clear but not so much code to write. Not less code to write but even (if possible) less clear then first hack was

The above example (the constructor) is bogus as an example of duplicated code or effort. The bottom line is that you don't have to type that all the time, just a fraction of it every few thousand lines. The reasons why may be very instructive if you're new to perl.

The long version does otherwise act as a good template, so that you can easily copy and add code to it if you can't be arsed to understand 'bless', class methods, and terse perl. That's probably why it is given in the book (You could just ask RandalSchwartz, who wrote the book; he hangs out in #perl on FreeNode (InternetRelayChat) as 'merlyn').

A quite legitimate WhyHatePerl complaint might be that it takes more effort to learn these details about Perl than about other languages, but that's the tradeoff for the stuff in WhyLovePerl.


I'm not arguing that Perl is incomprehensible. I've written code in it that I consider comprehensible, and I'd probably take Perl over Java, and I'll even defend the $_ pronoun when provoked. But to me, these nits are just completely indefensible. Perl is a badly designed language, and in a world with Python and Ruby, there's just no good reason to use it.
Moved from ThereIsNothingPerlCannotDo:

Actually, there is one thing a Perl script cannot do: be comprehensible to someone other than its author on first reading! (and, unfortunately, sometimes also the original author!)

Perl is quite arguably a bad language from a learning/readability standpoint. It is easy to write incomprensible Perl code. It is merely argumentative, however, to say that it can't be comprensible to someone other than its author on first reading. Unless you are talking about a complete perl novice, which I would argue is a very difficult test for ANY language. I certainly can't read Lisp or Smalltalk code, no matter how well written. I might be able to get the gist, and I could certainly learn the language, but no computer language currently exists that is both powerfully expressive and trivial to comprehend without training.

That said, you can definitely argue that the entire culture of Perl reinforces the notion that it is okay to write unreadable code. Certainly a large subset of it does.

On the other hand, my XP team had generated quite a large code-base, and the majority of it was *quite* readable to someone knowledgeable enough in Perl to understand OO Perl coding and with a relatively firm grasp on argument passing and references.

No language will allow a programming team to avoid having CodingStandards, (not the kind in a long document that nobody reads, but a team devotion to trying to make all the code look similar) if they want to make it readable. Things must be done as consistently as possible in order to be ideally readable.

-- JeffBay

Have you read any C systems lately? How about Sun's Javadoc? Most software has a face only its mother can love.

Well written Perl is perhaps more legible than well written code in many other languages. It has: In my experience, badly-written Perl looks bad. So I hack at it until it looks good, and voila! I have removed (most of) the logical problems I wrote in. --ColinvonHeuring
I read this page with mixed feelings. I love Perl, but it can be hard to respect yourself in the morning.

I have done some Perl work, some of it very non-trivial.

I was given a data warehouse (actually more of an offline ODS) and a set of large (13.5 GB) log files and told to find more than 3 million dollars in discrepancies between the logs and the offline data, and discover not only where they occurred, but also why.

After examining the offline tables and the text logs, I decided to have a whack at it in Perl (I needed the practice). It was Friday, so if all I got done was problem analysis, no one would complain. I drafted some attempts at reading the table dumps and comparing the values to the log values. By mid-afternoon, I had a two-page script that scanned and parsed 13+GB of table dumps and 13+GB of text logs, producing a profile, detail, summary, and conclusion (which proved to be correct) - and which executed in 35 seconds.

My results were validated (woohoo!) and I was asked to show how I had solved the problem in less than a day. I produced the two pages of Perl - and very nearly couldn't interpret what I'd written.
  Hey look - I did magic!
  What did you do?
  Well, I'm not really sure ...
On the other hand, I was given a project about a year later to review and validate a complete e-commerce system written in Perl 5.x to replace a wonderfully elegant, well written, well commented, perfectly modular system in Java - which didn't work and could not be maintained.

The Perl code was written by one guy. He had reverse engineered the Java system and and reimplemented it in Perl. My job was to confirm that the Perl code was correct, robust, maintainable; in other words, not like the existing Java system. I never saw the Java code.

The Perl code was as clean and lucid as anything I've read in any other language. Thousands and thousands of lines of modular, well-organized Perl. I hadn't even realized you could do that, since my own Perl style was "hack until it works" and I reserved the more formal disciplines for C/C++ and so on.

I will say that Perl has its own "state of flow" and while you're in the groove, everything makes sense. After a couple of "can't read what I wrote" incidents though, you'll want to reserve part of your mind to leave yourself clues that you'll need once you've "left the flow" because (if you're mortal) you'll need them.

-- GarryHamilton

You can write maintainable or unmaintainable code in any language. I have seen unmaintainable code in Perl, VB, COBOL, C++, SQL, C# and Java. What it takes is discipline which a distressing number of people lack. I wrote a large (~10K LOC) application in Perl and have no problem returning to it since I commented anything obscure, followed a fairly standard set of conventions and avoided tricky stuff. Basically in any programming language when I get to a point where I think "I can be clever in this part" my next thought is usually "should I be clever on this part?" and most of the time the answer is "no". Anyway, one nice thing about Perl is that it is very easy to build classes on the fly and create objects from them. And the horrible parameter passing? I think they stole that from LISP. I do not use it for everything, but when I need it it sure is handy.

Perl's status as a WriteOnlyLanguage is incidental (though surely not coincidental), and as several people have pointed out, code can be written badly in any language, and Perl code can be clean and readable. But the problem is not code written in Perl. The problem is Perl. It's a baroque, badly-designed language that tries to solve its problems by adding features to the language. Good languages start with a small core of well-designed fundamental features, and build up from there. Perl has so many features in the language itself that they can hardly be called fundamental, and most are designed badly, some terribly.
"ThereIsMoreThanOneWayToDoIt" results in lack of consistency. It means you have to learn to recognize multiple paths to the same thing.

This hits the nail on the head for me. When learning Perl I would use idioms/syntax preferred by the given author - only later to find exceptions in other writings - maybe better ways. I had to consciously put together my own zeitgeist that ended up evolving as my knowledge increased over time. Keeping this 'state' in my head was a major undertaking, in addition to the state of the problem I was attempting to solve or architectural behemoth I was attempting to construct. This experience actually shaped my preference to AvoidComplexity - and lead me ultimately to PythonLanguage - MalcolmCampbell
Perl seems to be a language intentionally designed to allow execution of newbie programmers' syntax errors while turning experienced programmers into gibbering idiots. -- DaveVoorhis The problem with Perl is not that it doesn't make sense, because it does... it makes sense in the manner of poetry, with brilliant puns buried in every line, and ferreting them all out means hours of play. Seen as a work of art, Perl is James Joyce and John Donne, Milton and Don Maquis, and Shakespeare throwing in a brace of dirty limericks to salt the pot. -- PeterdaSilva on HatesSoftware
The problem with Perl is that it has every feature a programmer could want, built in. It needs this because it has every "feature" a programmer could want, built in.
"Accidental syntax": http://www.plover.com/blog/prs/accidental-syntax.html

You move a mole on someone's face one centimeter and they become a whole different person and nobody knows the difference... at first. --top
A summary of a lot of complaints on this page would be "X is hard if you don't know perl really well." That would be an explanation behind a further selection of them.

Because almost anytime you mention it, someone starts complaining how hard and bizarre it is, often overshadowing (or halting) a useful conversation. This includes in perl-specific IRC channels. We need something like a Godwin's Law applied to the complexities of perl so that, at least, more useful criticisms of perl can enter the mainstream.

Because almost anytime you mention its pitfalls and problems, some fanboy starts complaining about how the people are complaining about legitimate pitfalls of the language.

An example would be that subroutine and method calls are horribly slow, beyond the scale of other dynamic languages. View some of the demented code I've written for the GreatComputerLanguageShootout as a result. --JesseMillikan
ComparingDynamicVariables discusses dynamic variable comparison issues and techniques, and explores different approaches that Perl could have taken.
Because someone, somewhere, thought it would be absolutely cute to use the following for error reporting inside of Perl modules:

carp, cluck, croak, confess.

What do these mean? How are they different? Which is more or less severe? Perhaps the most important question, what brain damaged neckbeard thought these were a good idea?

That's not really an answer, y'know? Being glib isn't an alternative to addressing a reasonable concern.

   sub croak   { die  shortmess @_ }
   sub confess { die  longmess  @_ }
   sub carp    { warn shortmess @_ }
   sub cluck   { warn longmess  @_ }

Perl is the Quasimodo of programming languages: ugly as hell, but you want him on your team.

Some love Perl, others hate it. It's obvious when you read these rants. However, you can't argue with CPAN ... obviously enough people find it useful that they churn out lots of wonderful high-level libraries. Need to write a quick SOAP client? A few lines of SOAP::Simple will do it. Need to muck around finding the optimum value of something? Use Math::Amoeba. Or need to do some clever classifications? AI::NaiveBayes1. How about including some native non-perl? Use Inline;

Sure, other languages have big libraries too. But since there is so much free Perl out there, obviously there are lots of programmers who find it a good language to write in. Let's face it, every language sucks: they all suck in different ways.

This would just about make a good tweet.

Oh come on. I'm seeing all of this hate for Perl all over the place. It's unreadable, this language is better, that language is better. This language FORCES you to use good syntax and coding technique, this language has better structure ... blah blah blah.

There's the problem right there. Perl offers you too much creativity and freedom. You can do things as quick and dirty as you want. VERY dirty. Now whose fault is it that your Perl code is unmaintainable? Mine? Larry's? The person who started this thread? Your own? AH-HA!!

If you're a pasta chef, it's your own fault - not the language's. Stop blaming the tool and start blaming the user ; Go yell at the mirror. When you want all the stops pulled out, Perl's there for you. If you want to be forced to follow every little rule - there's the other language everyone else is using - go use it. --Kyanwan

Based on all of the discussion, I can only say that it would be my fault for picking Perl in place of what might be a better language and for any unrealized expectations that the average programmer will abuse this creativity and freedom less than for other languages, potentially costing me substantial amounts time (for maintaining and understanding old code) that most likely cannot be mitigated through any development speed gains resulting from the increased flexibility. Perhaps a more specific argument will be more convincing.

elsif. Couldn't perl just use "else if" or "elif" (if it had to be one word)?


EditText of this page (last edited April 8, 2014) or FindPage with title or text search