Return Styles: Pseud0ch, Terminal, Valhalla, NES, Geocities, Blue Moon. Entire thread

Perl: Jewel in the Rough or Scourge of IT?

Name: Anonymous 2013-04-24 11:29

Name: Anonymous 2013-04-24 18:06

>>4
This talk is about why Perl 5 sucks (although Perl 6 became arguably worser, just it's grammar file is about 6500 lines).
- Abominable syntax: Perl's syntax is so non-orthogonal and hideous, it shades all other Perl warts (which are ugly). Perl's grammar isn't context free and can not be reduced to BNF. Perl's parser (perly.y) is 760 lines long (larger than C++ and Haskell), while the lexer (toke.c) is 11000 lines long, which gives a clue how many kludges Perl needs that the parser can't handle itself. Perl grammar is inherently ambiguous, and the resolved by using dodgy look-ahead heuristics. For example, is "print $f +$g" writing the positive value $g to the file $f, or printing ($f+$g) to STDOUT? Is `{ local $a => 1; ... } print "old a=$a"` starts a scope block or a hash? Other example `f / 25 ; # / ; die "oops!";` can parse two different ways: if `f` takes no arguments, then first statement is a division in void context, and the rest of the line is a comment, otherwise it parses as a call to f() with the result of a match operator, then a call to die(). In general, Perl cannot be parsed, because Perl's syntax is undecidable: http://www.perlmonks.org/?node_id=663393
- Broken scoping: Perl doesn't require variables to be declared and just referencing a name introduces a variable, resulting into cluttered global scope and absence of undefined-variable warnings. Although Perl has my and local keywords, they are not enforced, so nobody uses them. All variables have to be prefixed with ugly $ @ % & sigils all time, just to disambiguate in case variable doesn't already hold a value. It is typical to see crazy code, like "my $fh = do {local(*FH);};", which creates a local typeglob named FH and immediately takes it out of scope, returning the now anonymous typeglob. Perl's broken scoping is a fundamental flaw, which cannot be fixed.
- Inconsistent type system: Perl implicitly coerces string to integers, so "123abc"=="123def" and "  123xyz"==123, and even 0.0=="". Sigils everywhere make type system depend on scoping. No OOP encapsulation or overloading: Perl has a mess of unorganized global functions. Most typing mismatches, instead of generating error, return some nonsense value, so void+123 or @x+%y==0 would give you untraceable bug. Finally, Perl has no booleans, so there is no way to discern 0 from false; moreover "" and "0" are false too, but "00" isn't, despite "0"=="00". For some reason void acts as true, but referencing undefined variable returns false. Integers are represented as floating point values, so 99999999999999999999==100000000000000000000.
- Perl is hard to learn, due to non-orthogonality by design: Perl's goal of bundling basic Unix utilities into one language was achieved in haste, ending up producing numerous sublanguages loosely glued together, making Perl look like a deficient Unix clone, where all commands are builtins. Perl implements a lot of standard library on syntax level, making language enormous in size: for example, instead of being a library function, regular expressions are implemented as syntactic construct, allowed at unexpected places, like in "print if /regex/", which also gives no clue what it prints or takes as input. Or take "pos($x) = pos($x)", which does bizarre magic at resetting regex. Other example is ".." operator: "print 1..3" produces a sequence, but "print if 1..3" interpret 1..3 as a range of input lines. Then Perl has a lot of duplication: for example, Perl has `not` operator, but for some reason also includes `!` and `unless`, while keyword `if` is overloaded as infix operator, and don't forger about cryptic if?then:else operator. Having a myriad of these special cases, Perl rejects logic and appeals to humanities and theology students, who love learning random facts by rote memorization, and for whom $_ and <> are perfectly clear, even intuitive. The standard Perl documentation contains over 70,000 lines, add to that all the documentation on CPAN modules, and you face a pretty substantial base of prose just to begin with Perl. "Perl users were unable to write programs more accurately than those using a language designed by chance." -- http://ecs.victoria.ac.nz/twiki/pub/Events/PLATEAU/Program/plateau2011-stefik.pdf
- Perl is inefficient: broken scoping impedes efficient compilation and bad type system hinders any optimization, making Perl agonizingly slow. Aggravating Perl's condition are naive reference counting garbage collector and unparsable syntax, requiring solving halting problem just to parse a Perl source file.
- Perl code is unmaintainable, "clever", unreadable and obfuscated: Perl encourages packing unrelated concepts into a messy one-liner, impeding understanding and modification; TIMTOWTDI-redundancy guarantees style discrepancies, misunderstanding and pointless flame-wars among developers, which is aggravated by the size of the language. Finally, Perl isn't modular: it is common to see Perl script 6000 lines long.

Name: Anonymous 2013-04-24 22:02

>>17
people don't use them correctly doesn't mean it's a bad language.
Yeah. Blame the victim.

Befunge is a tool, the fact you can't use it correctly     doesn't mean it's a bad language.

When faced with criticism, all Perl apologists spit generic arguments, starting with banal ad-hominem, which speak for themselves: "all languages are turing complete", "languages are just tools", "no language is perfect", "good developers can write good code in any language", "Perl was never intended to solve problem X", "Perl isn't the problem, bad programmers are", "products X was built using Perl, so Perl is good enough", "there are two kinds of languages: the ones complained about and the ones nobody uses", "Perl is free, hosting is available, PHP programmers are cheap", "clients don't care what language is used", "Perl has great community, we are like family", "if you do X then problem Y would be less noticeable", and a myriad of variations. The best examples of Perl apologetics, like https://news.ycombinator.com/item?id=4177516 , contain gems in the lines of "Sometimes you don't care if a function succeeds" - in other words, Perl community doesn't care if their code succeeds.

Newer Posts
Don't change these.
Name: Email:
Entire Thread Thread List