''And [Python] looks like executable whitespace. These variables are actually hardly a design decision on [Perl]'s side - 99% of them existed in [AWK]. Much of the linenoise comes from the [AWK] and [SED] heritage actually. The majority of it is loathed by many [Perl] hackers as well. Too much of I/O is controlled by global special variables; Larry himself has said this situation needs fixing. Of course not much can be done for [Perl]5. Unlike the [Python] and [PHP] folks, we don't go breaking people's old scripts willy nilly :)'' --AristotlePagaltzis 

  

 ''[Perl] didn't get its line noise from [AWK]. All [AWK] has is the $ operator for getting from a field, eg $3 will get the third field, $x will get the field for the number held in x. [sh] has $ on it's variables and shares some with [Perl], but many are unquie to [Perl], eg $# is the output format for printed numbers in [Perl] and the number of command line arguments in [sh].'' --JonPurvis 

  

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

  

  

 ''Because if things are designed well enough (!) you don't need that low level of access, even to do unintended things. Higher order functions, complex and nested types (lists, dictionaries/hashes, strings, in any combination), and a strong but lightweight object system (i.e. minimal syntax and typing) let you hack things up for the unusual case without making the usual case burdensome. C hides the ability to check or change the flags bits when arithmetic operations occur but assembly lets you do this any time you want, or to have a different function call method (e.g. for tail calls). We should all code in assembly all the time. How is that better?'' --JaredUpdike 

  

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