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.'' 

  

  

  

 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? 

  

  

 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 coding[2], 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. 

  

 !!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: 

  

 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?"