Penguin
Note: You are viewing an old revision of this page. View the current version.

I felt the need to rant, so why not? :)

Nest types suck

In perl you can't do anything obvious like create a hash of a list of strings trivially, you have to spend your entire time worrying about references. Why? I don't know.

A Gazillion obscure operators and magic variables

In perl you're never sure the operator this person is using is. Perl has operators and variables names after almost every punctuation key on the keyboard. (Pop quiz: Which punctuation keys on a standard qwerty keyboard, aren't valid perl variable names?)

True, but you don't need to know or use these variables. Just because you can, doesn't mean you should :) $! is the string message for the last error, $@/$$/$% do things with references to those data types, $# is the length of a list, $^ is magic for which OS you're on, etc etc. But not knowing this doesn't make perl any harder to use. Most punctuation also does something in C -- you're just more used to them.

Isn't this based on the assumption that "use" is only writing code? I would argue that since you (and others) will end up having to read, and interpret the code at some point, complex and obtuse constructs like this do make the language harder to use. Since they are there, they will be used, so you have to know them to be able to understand the code. -- StephenLewis?

Also, just to be pedantic, the node is WhyIHatePerl, not WhyCIsBetterThanPerl ;) --StephenLewis?

This was ment as a random rant, as someone asked me what I disliked about perl, so I thought I'd jot a few of them down. It's not ment to be a complete critism, most of it is mostly due to my not knowing the language properly.

The thing is in perl you can write nice and easy to read and maintain programs, however people don't. Sure I can avoid these things, but it doesn't help me when I'm trying to debug some body elses script. C uses a lot less punctuation than perl, this is easily proven by the fact that perl uses mostly the same punctuation as C, and then adds it's own ones :) I don't think C and Perl really should be compared. They are completely different problem domains. I've got a rant growing somewhere about C too :) Compared to python, perl looks like executable line noise.

Simple things are hard

Someone once said that the definition of a low level language is one that requires you to spend your time worrying about the irrelevant. Perl must indeed be a low level language. Trying to figure out how to pass a list to a function, create a local variable in a function, nest types are all things that are difficult to get "right". You have to know a magical encantation to do them. Why don't they do the right thing?

I don't understand the question... To pass a list, you just pass it. Or is the problem that all arguments get flattened into one list? That's a fair gripe. Then again, how do you pass a list in C? Pass a pointer? Then you have to pass a list count as well.

Lists get flattened, variables by default are global, nested types aren't really nested (they're just references). The point of a scripting language is to get on and do what you want, not spend time thinking about how you are going to achieve it. I'm sure there are other examples of perl doing counter intuitive things by default and requiring you to work around them. These are mostly historic since perl grew out of a smaller language into a bigger one. But I think these are good examples of why you shouldn't use perl for a large project. Perl is good at parsing text files and outputting a nice summary, or munging it into a different format. Perl is not something that you should be writing large projects in. Yet people still do. (People still write large user space projects in C too for some unknown reason).

To effectively work on a large project you've got to manage complexity, with perl unless you are very strict, the complexity gets away from you. The thing is most programs start 'small' (I'll just write something that parses subscribe/unsubscribe requests and updates a sendmail alias) but ends up growing over time into a monster (majordomo...) Compared to almost any other language, Perl makes you spend a lot of time working with the irrelevant.

There's More Than One Way To Do It

Perl people say this is a good thing, but the problem with theres more than one way to do it, is that noone ever does it the same way twice. To properly read a program you have to understand the 'idioms' that that program is written around. In Perl it's difficult to realise that "ah, thats a switch statement, I can see what that's going to do" because in perl there is no switch statement, you can roll your own (a nice idea), but, you can get half way through and discover someone's modified their idea of a switch statement slightly and now it has a side effect you didn't realise until you read the code very very carefully. In most languages you can learn a couple of constructs (for, while, do..until, if...then...else, functions) and you've learnt a good chunk of the language and can read most of it. (Even C++ which has a huge number of things (virtual private classes? who on earth would use such a thing?) you learn about the various flow control structures, and how to define/call functions/methods, and you can follow a good chunk of C++), however in perl, since theres so many ways of doing anything you have to learn all the idioms before you can read a sizable chunk of perl code since they are all used, randomly.

There's More Than One Way To Do It, part 2

(GlynWebster's two cents.)

When Larry Wall and Perlers say "there's more than one way to do it" they seem to be talking about syntax rather than the semantics. They really mean "there's more than one way to say it". I'm not sure that Perl gives anyone more ways to actually do things than any other well-stuffed scripting language. It gives people lots of ways to write down individual statements, which gives them a sensation of freedom while coding2?, but only seems to lead to confusion and trouble later on. The languages that really give you a lot of ways to do things, like CommonLisp, are far less popular.

I think this emphasis comes from Larry Wall's background in linguistics. With a natural language having lots of ways to say things is a good thing, but semantics are something that linguists try not to think too deeply about. The semantics of natural languages are so poorly understood that it's a bottomless pit best to stay out of. But computer languages are not like languages. They are "notations" more akin to the various notations used in mathematics. Larry Wall don't believe this. Larry Wall seems to be be paying more careful attention to semantics in his "Apocalypse" series of design documents, but he doesn't seem to learnt his lesson about syntax -- Perl 6 looks like it will be even hairier than Perl 5. He's more than smart enough to design a computer language, I know I couldn't do what he's done. I just don't feel like following him because I don't think he has taken the right approach, and has the wrong temperament for his task -- a belief that elegance is possible and a mathematician's urge to reduce things to their essentials seem to be called for.

Cause doesn't always preceed effect.

Perls operators like "unless" mean you can spend a long time reading a block of code before realising that the entire block doesn't get called because there is an "unless" at the end of it. Cause should preceed effect, not come half a program later.

<Matthias> hmmm... and unless is nice in some cases... it can really help

making code readable... unless you abuse it

<Isomer> I think that sentance just proved my point

Again, just because you can code something in one way, doesn't mean you should. I personally don't use the 'unless' keyword because it doesn't flow the same way a C program would. But then again, it is not uncommon in C to see do { block } while (0); This isn't exactly crystal clear either unless you are a seasoned C programmer.

The problem is that most of the code at least I interact with is written by other people, or at least is modified by other people. If a program is small, then it's irrelevant, people will just tend to rewrite it instead of modifying it. I find very few perl programs that I honestly thing are 'readable' and 'clearly throught out', this is perhaps because I'm not very experienced in the language, but when compared to when I was teaching myself C, I find perl to be much worse.

The thing that made me add this on this list was trying to debug some program that appeared to go off and do something totally unrelated, then had an unless over a screen away which made the entire point moot. Probably it evolved from a single line with an obvious 'unless' at the end of the line, which grew as this case got more and more complicated into the monster I was forced to do battle with, but it's symptomatic of the problems you end up with in perl programs. This is probably a special case of TMTOWTDI, but always something I felt very jarring.

Perl implicitly does things behind your back.

Perl's $_ operator saves a lot of typing, but makes your program have a large hidden dependancy. Like the "more magic" switch of lore, changing something unrelated that does absolutely nothing obvious can cause your program to crash. Is it safe to insert some code in the middle of this block? Who knows! It could disrupt the fabric of space time that this perl program exists in.


Some additional discussion from the page of JaredWigmore?:

I dislike ...Perl (too simple, too slow and doesn't scale)

... I don't like Perl either :) -- PerryLorier
... I also think Perl sucks perhaps a couple of LoveLace, no matter what you compare it to! :) Try Python, it's great! -- zcat(1)
Perl combines the worst aspects of C, BASIC and LineNoise -- Anon
I don't like Perl either. I got about ten pages into the manual (somewhere around the "you are not supposed to understand this" part) before I started to think I was having my leg pulled. Then I discovered Python. ... --GlynWebster
Heathens and philistines, all of you! :) A language is only bad if it is not expressive enough. If it is, and Perl is plenty expressive, then it's the programmer who makes it what it is. "If it was possible to write programs in English, we would discover that programmers can't write English" --LarryWall Perl is easy to abuse because it's so expressive you can do things in any number of ways. Unfortunately, it is so easy to successfully say something the computer will understand that few people bother to think about how to say it well. Python is entirely on the other extreme of the spectrum, and I find that extraordinarily obnoxious. --AristotlePagaltzis

But Python is an attempt at saying something well. There's elegance and forethought in the design of Python that's missing from Perl. "Saying something well" in software involves making the entire program well-structured, well-structured and comprehensible to others. Perl's great number of syntactic options at the expression level doesn't help there. --GlynWebster
That you can change the sequence of things in a sentence - that is what my point is about. It does not let you chose between "I want to say the same thing differently depending on the situation" vs "Depending on the situation, I want to say the same thing differently" or even "Differently do I want to say the same depending on the situation". Neither is the verbosity is up to the programmer to choose in to Python. I find it very frustrating how Python doesn't let me get to the point - and no, that doesn't mean my Perl code is compact and incomprehensible, au contraire. I recently argued such a point with RandalSchwartz (who originated the term "Perl hacker"). Perl gives you the freedom to do whatever you want. The problem, as the LarryWall quote I cited hints at, is more due to the fact that, well, the majority of programmers are mediocre at best, so Perl is a dangerous tool in their hands. It doesn't constrain bad habits at all so they end up writing horrid Perl code, where Python would have forced them to follow a decent style. Why's that a problem? Because an advanced programmer who (should) no longer be in need of those tight confines can't escape them. Perl is not a language to learn programming with; it's a language to get your job done. Just like Pascal is a neat language for a beginner to start out with, but not for an expert to get things done in. --AristotlePagaltzis

The thing with Pascal is that it was impossible to do most things. Standard Pascal didn't treat files like most newer OS's did (a stream of bytes? wazzat?), but it's big failing was that the size of the array is part of the type, and there was no way to write a generic function to handle arrays of varying sizes. Since strings were a kind of array, you couldn't write a function to take a generic string. Sure, langauges like TurboPascal resolved most of these issues in incompatible ways. Delphi shows that Pascal can be a nice language when "touched up".

Perl may be expressive, but the problem is that you have to maintain other peoples perl programs, and since other peoples Perl programs are difficult at best to modify, you have a problem. while this may not be the language's fault, it is a problem with the language IMHO. --PerryLorier


2? I think a similar, pleasant feeling of busyness while coding explains some of the popularity of C. "I'm doing lots of work, I must be getting a lot done. Right?"