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

Perl

Name: Anonymous 2014-07-13 18:02

What do you think of using Perl? If you don't like it, which scripting language do you prefer?

Name: Anonymous 2014-07-13 23:04

This talk is about why Perl 5 sucks (although Perl 6 became arguably worse, just it's grammar file counts about 6500 lines: https://github.com/perl6/std/blob/master/STD.pm6).
- 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? Does `{ local $a => 1; ... "` start 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 strings 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.

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