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. 

  

 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. 

  

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

  

  

  

 ---- 

  

  

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

  

 ''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|http://www.perlmonks.org/index.pl?node_id=239615] with RandalSchwartz (who originated the term "[Perl] hacker"). [Perl] gives you the freedom to do what__ever__ 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''