Why Hate Perl
Why Hate PerlSee 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::ModuleLessIsMore !! use cpanminus (http://search.cpan.org/perldoc?App::cpanminus) !!
cpanm Some::ModuleUgh, 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";versus:
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.
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.
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.
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.
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...
if(foo) doSomethingnote 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
1;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.
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:
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.
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.
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:
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.
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 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?
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)?
I think perl has about got the monopoly on (i wont say scripted) no-compile languages as far as flexibility and extensibility goes. As far as hating it, I agree with Kyanwan. Do you remember everyone? Your early days programming teacher telling you not to write spaghetti code (like gwbasic and C they taught in high school back then, ive no idea what they teach now). Anyhow, I just hope no high school teachers ever decide to teach perl because they will have such a mess if the BASIC days are any indication of that. -- Gabriel T. Sharp :)
There Are So Many Ways To Do It That When The Code You're Maintaining Does It One Way And It's Gross You Have Literally No Idea Whether They Did It For An Actual Reason --TaliaRinger
EditText of this page
(last edited November 20, 2014)
or FindPage with title or text search