See 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::Module LessIsMore !! use cpanminus (http://search.cpan.org/perldoc?App::cpanminus) !! cpanm Some::Module ''Ugh, 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. * ''There are also people who are prepared to read manuals, but why ruin a good rant. Please, carry on.'' These people are very useful to have around, sometimes. * ''Yes, these people are like mathematicians, with all of their silly and inefficient signs for integrals, sums, whatever - why not spell it all out in plain English! That would be more Rational, would it not?'' But I no more want to use the tools that those folks get off on to write my software than I would want to make up my own wet collodion plates to do photography. It's not masochism that makes people think that this kind of thing is good, and it's not lack of thought, either, though it kind of looks like it. Maybe there isn't even a word for it. But this way of thinking about software, what it's for, and how to write it, that Perl seems to represent is not something I even want to know exists, never mind get involved in. It's creepy. 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. * ''Comment: That's silly. Using prefixes is trivial and irrelevant to the point you're making. I suppose you put down Python because you have to manually include various modules - like regular expressions - which are built into Perl? Also, you can always use English;'' ''Clearly, the elegant iconography of code, a practice that extends far back in the history of mathematics, and championed by the likes of Leibniz, is completely lost on folks who make such arguments. The iconography of perl takes advantage of the signifying capability of the ASCII character set, by assigning simple mnemonics to each prefix - e.g. $ = value (as in "show me the money"), @ = array (as in there is a little a in there), % = hash (as in a pair of little round thingies), etc. It takes a second to learn and simplifies things immensely, where other languages force a roll-your-own Hungarian syntax that is both ugly and unscannable, since you actually have to read a variable's name to determine what the heck it is. Languages such as Java and Python remake the mistake of BASIC, which falsely assumes that spelling things out makes things simpler. Not! The simplicity of language lies in its morphology, syntax, and pragmatic structure. Larry, a linguist, knows this.'' (It is also HungarianNotation, which is just a smidgen shy of being universally rejected by any programmer with even 3 days of coding experience. --SamuelFalvo) See TheProblemWithSigils. * Stop trying to make a script language like perl sound so noble. A linguist should know better then to design a programming language after natural language. A natural language, as long as it is still used, is a moving target. If you write a book, the time will come when people can't understand it because the natural language has shifted away from when you wrote it. Also, by the nature of language, it is hard to remember. If you don't visit a portion of it for a time you will loose it. The exact opposite of riding a bicycle. ** This is a ludicrous argument. Natural language is understandable for hundreds of years past most noticeable changes. Go and make your arguments about perl's deficiencies when /any/ computer language comes /anywhere/ close to the lifespan of natural languages. -bjc *** There is nothing "natural" about using symbols such as # $ % @ ->{} () [] in all conceivable combinations all over the place. When I look at somebody's Perl code I get indigestion. ---- 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 ThreeStarProgrammer''''''s 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.'' * Actually, no. Ruby's "*" doesn't "flatten," it "splats" (or unsplats, as the case may be). Flattening and splatting are different. * ''I admit I only played with Ruby and Rails for a few days (some time ago)...and was baffled when I needed to pass an array as separate arguments to a function. I found "splat", and it did what I wanted it to do.'' : Of course, there's always the HaskellLanguage way: "function list1 list2" for passing two lists, and to pass two lists flattenend "function (list1 ++ list2)". I don't see how automatically flattening the lists is the preferred default. It is not the obvious or naturally expected behavior to anyone but a PerlLanguage weanie. ''exception handling = die; returns = return scalar or list (and you caan find out what you want if you really want to (but you shouldn't)); parameter handling - lists do get flattened, but typeless languages have the amazing advantage of not requiring stupid things like C++ templates or the java generic language package; prototypes are for automatic input conversion, not. -- JeffBay '' : Perl doesn't mess up lists in method parameters because it's typeless. It messes up lists in method parameters because Wall & co screwed up when they defined that part of the language. Check out RubyLanguage for an example of avoiding the braindead Java collection classes while still making it painless to pass collections as method arguments. : To JeffBay: Surely the comparison of 'die' to real exception handling is a joke? Also, nobody is denying the benefits of typeless languages: the TclLanguage is perhaps even less typed than Perl (lists also being strings) and the PythonLanguage also is loosely typed and yet there is far less messing around with parameters and magic than with Perl. : ''See ExceptionHandlingInPerl'' '' You surely made a mistake somewhere, the PythonLanguage is extremely strongly typed. It's typing being dynamic and late-binding doesn't make it loosely/weakly typed. '' 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.'' * Pretty ignorant example. Interesting that you picked a module that is so spelled out to illistrate your point. Could you tell me, without looking, what Gantry does? When I was forced to use perl and had to look for modules on CPAN I can tell you there were plenty of modules that it is not easy to figure out what they do. ** Could you tell me what Django or Rails do without looking? It's not just Perl projects that pick creative names, dude. I concur with the above criticisms, ''especially'' the lack of real exception handling (and suggesting die is a bad joke made all the worse by the fact that it's a serious suggestion and even a widely-used practice) and ''really especially'' the crippling difficulty of passing multiple arrays to a subroutine. This latter fault is, i think, actually a symptom of a general failure to make arrays work sensibly - rather than treating them as first-class objects, it's almost like the interpreter just rewrites them as a sequence of scalars and pretends they never existed. Consequently, passing two arrays to a subroutine is a hopeless case, and passing in or returning an array (or even moving it from one variable to another) actually makes a copy (if I wanted a copy, I'd ''ask for a bloody copy''; now tell me how I'm going to get this data out of my subroutine without using the return value or a global!). Of course, all these problems can be overcome by using references, but in more considered languages, like Java and Python, this is simply the normal behaviour of variables, and things work without half a dozen extra characters. And while we're at it, why do LarryWall and company think that every problem can be solved just by throwing syntax at it? I hate perl. -- TomAnderson : Can you clarify why you think the die/eval exception handling model in Perl is so bad? It does everything that I need exceptions for. * Because it doesn't have exceptions? It has a way to run a string in a different interpreter and check a string to see if it died. Of course if you "throw" exceptions, take care to reset the __DIE__ handle or you might get caught by code that naively thought die meant die. ** Begging your pardon, but you're mixing up two uses of eval. There is eval EXPR, which does as you say, it runs EXPR in a different interpreter, and there is eval BLOCK, which just catches die statements and assigns the die output to $@. Sure, it's a very basic way of handling exceptions, but it is still not quite what you say it is. ''JUST PASS BY REFERENCE! RealProgrammer''''''s have always passed by reference anyway, it's only when I read this I even realized that passing multiple arrays would be a problem without references. Since I naturally create arrays and hashes as references in the first place - eg my ($foo) = {}; - then I never even worry about the problem. Just use references and quit whining.'' 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... * Pull the "if $foo" out from between the actual statement and the ";". * Put parentheses around the expression after the "if". All this in addition to adding the "{" and "}" that you would have to do anyway. Just brilliant. ''Id like to add that Awk does it best:'' if(foo) doSomething ''note 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'' ---- * I'd just like to address the "impossibility" of passing two arrays to a function in Perl. I'm not sure how List::MoreUtils accomplishes it! Unless it's a freaking prototype like 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 Why''''''Hate 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. * The syntax of Perl borrows from C, Basic and Shell Scripting. Most things can therefore be expressed in three different ways. And three different ways in different parts of the same statement. * Perl provides many shortcuts to express variables in a couple of characters, or to automatically provide variables that are not mentioned. * JavaScript - and incredibly powerful and graceful language (even potentially a LISP!) but until the creation of some popular libraries was mostly written procedural and straight-line on hoards of web pages--with globals. I was writing it OO then. Should I have hated it because soo many people propagated deplorable JavaScript? ''Comment: It's almost like unreadable/maintainable code was woven into the design of Perl. use strict; use warnings; NuffSaid.'' ---- 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: * The terser the source code, the better. ''This is pure FUD.'' (Actually, it's a good rule of thumb. The problem is that Perl often thinks that "terse" = fewer characters as opposed to fewer concepts. Perl encourages you to pack so many concepts on a line (especially if you use regexps) that a line of Perl can sometimes be roughly equivalent to, say, four lines of Pascal. Not that PascalSucks not. * The more ways there are to do something, the better. These are simply asserted as articles of faith that you may not question without invoking the wrath of the perl gods... but common sense and everyday experience tell you they are just plain wrong. Proceeding from a wrong premise, it's no wonder that the language has developed into a Byzantine monstrosity and is beyond hope IMHO. ---- 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 RegularExpression''''''s, there's sample code for finding all the "http"'s in a file and printing them: while ($line = ) { if ($line =~ /htt''''''p:/) { 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 () { print if /htt''''''p:/; } 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/,;'' ''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: * Why on Earth does Perl distinguish scalars from references? The only answer I can think of is compatibility with Perl 4. * Why doesn't Perl have named argument lists? I can think of no good reason for passing all arguments in @_ by default. All the dynamic languages allow the programmer to fetch all the arguments in an array, but Perl 5 is the only one I know of which permits ''only'' that mode. * PerlGolf. Here's the shortest possible class definition in Perl 5 which permits inheritance: package Example''''''Class; 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 Example''''''Class; 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. * '''"Allows inheritance" here means "Supports ''direct'' use of ''that constructor'' in subclasses".''' ** I can't think of another language that supports this. (AnswerMe: What languages do?) * Even outside normal inheritance trees, constructors like this do not need to be repeated. (I can think of three or four techniques.) * Even perl modules that are OO-heavy don't contain very many classes. * It's a bit bloated, including the prototype thing. The golfing is fairly clear if you understand Perl OO to begin with. The long version ''does'' otherwise act as a good template, so that you can easily copy and add code to it if you can't be arsed to understand 'bless', class methods, and terse perl. That's probably why it is given in the book (You could just ask RandalSchwartz, who wrote the book; he hangs out in #perl on FreeNode (InternetRelayChat) as 'merlyn'). 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. --JesseMillikan * Exceptions are strings by default, making error recovery difficult at best. You have to munge strings instead of, you know, just switching by exception type. Sure, you can create exception objects and throw them, but all of the built-in stuff just throws strings. * Oh, and most operations don't throw exceptions by default. 'open' returns undef if it fails. What year is this again? WHY, Larry, WHY? You see the open(FILE, $filename) || die $! idiom all over the place. Why do I have to type that all the time? This is a language which values terseness? ''Probably backward compatibility. perldoc Fatal for an alternative.'' * File handles as special variables? Yuck! ** "Recent versions" (5.004+) hide this. See perlfaq5 on the web or with perldoc. * The * operator? YUCK! ** You mean the * sigil? If you use indirect filehandles, you probably won't need them (directly) in your whole professional career. * Why do imported modules have to return a true value? ** This trips me up. I hate it. (I'm not a ''total'' SmugPerlWeenie.) --JesseMillikan *** This "feature" should be removed. Its original intent was to be able to indicate that your module did not load correctly. But since that's a fatal error, you can just use die() instead. --ColinvonHeuring * What's the right way to get the length of an array? Is it the 'length' function? Why, no! It's a function called 'scalar'. I understand why it does this, but there are millions of lines of broken code because 'length' does something weird when applied to an array. ** Read the documentation of the function before you use it. Also, in Perl a string is not an array of characters, and it's not supported to think of it that way. If you need such a thing, use split(). --ColinvonHeuring *** Or, use a language where strings really are indifferent from sequences of characters. If they weren't in fact, then you'd never be able to select a span of text for cutting and pasting. * my $scalar = %hash; # Assigns '''what''' to $scalar? You're kidding, right? ** What do you think it should assign (keeping in mind that references are still a "new" idea)? *** It should be a type mismatch error without an explicit ''function'' which returns a reference to its argument. **** It gives a boolean value that tells if the hash is empty or not. This is pretty darn useful. If the hash is empty you get undef, otherwise you get a useless string with info on the number of buckets used vs available (e.g. '4/32') that it is guaranteed to evaluate as true in a boolean context. In summary TRUE if non-empty, FALSE if empty. I'm not arguing that Perl is incomprehensible. I've written code in it that I consider comprehensible, and I'd probably take Perl over Java, and I'll even defend the $_ pronoun when provoked. But to me, these nits are just completely indefensible. Perl is a badly designed language, and in a world with Python and Ruby, there's just no good reason to use it. ---- '''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 CodingStandard''''''s, (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: * A high degree of inbuilt abstraction * The ability to say the same thing in many different ways. This lets you choose the most readable version in context (on the other hand, it is precisely because of this flexibility that badly written Perl is perhaps more unreadable that most other languages. Few people take the time to work out which idiom would be more readable in a given context.) ''In my experience, badly-written Perl looks bad. So I hack at it until it looks good, and voila! I have removed (most of) the logical problems I wrote in. --ColinvonHeuring'' * "Looking good" is highly subjective. I've had the misfortune of maintaining some Perl code which was mostly well factored and otherwise "looked good." There were a ton of idiomatic programming left in the otherwise apparently clean Perl code. ---- 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. -- GarryHamilton ''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 * Quit being such a rude, arrogant bastard DaveVoorhis. And don't be correct either. That is NotNiceEnough. And don't hold back DaveVoorhis, tell them how you ''really'' feel. The problem with Perl is not that it doesn't make sense, because it does... it makes sense in the manner of poetry, with brilliant puns buried in every line, and ferreting them all out means hours of play. Seen as a work of art, Perl is James Joyce and John Donne, Milton and Don Maquis, and Shakespeare throwing in a brace of dirty limericks to salt the pot. -- PeterdaSilva on HatesSoftware ---- 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. * ''Yeah I mean, if you know assembly language well - you can pretty much code in it as fast as any language, as long as you put the assembly code into abstractions and mung it around in your editor just the right way. Just because assembly code is hard, does not make it more productive than say a language that isn't as hard! On the contrary, the harder the language is and the more bizarre it is - the more productive all coders should be.. especially geniuses who don't make mistakes any time. --DevilsAdvocate'' ---- WhyHatePerl? 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? * That's the linguistic side of Perl. They mean whatever you want them to mean. Semantics! -- brider That's not really an answer, y'know? Being glib isn't an alternative to addressing a reasonable concern. * Reasonable concern? carp: 1. verb. to say or tell 2. verb To find fault with. (1913 webster). perldoc Carp is also helpful and answers all your questions except the last in the first section. Your not liking the name choices is rather irrelevant. I'm not going to argue their meaning is intuitive, but given some knowledge of the English language and the skills involved in reading and understanding a dictionary, I think anyone can live with those function names. If dictionaries are too much, use aliases. -- Jaroslav Rakhmatoullin 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 ---- CategoryPerl, CategoryRant