Tim Blames Perl

Come on. I know that good developers document their code, but it's the mark of a bad language that lets (even encourages in the case of perl) developers make their code pretty damn incomprehensible to other developers.

So, C, C++, Java, shell scripting, ML, Lisp, Scheme, and Prolog are all bad languages?

What's a good one then?

Jim,

Since when can an inanimate programming language encourage a developer? For that matter, what programming language knows the skill level of all the developers that will look at code written in it?

Sounds like you're looking for a sentient being, not a programming language.

Consider math, for example. Everyone understands 2 + 2 = 4, except the people who don't.

I am a developer and I don't understand much Python code, so naturally Python is a bad programming language.

Hell, I have even come across Visual Basic code that took me a while to interpret due to the lack of comments.

On a similar vein, a reader feedback in a recent eWeek magazine criticized PHP (which had been covered in the previous issue) because it encouraged developers to write insecure code.

Languages of course encourage or discourage certain behaviours. Case and point, CFML encourages developers to write application logic first and presentational logic last.

That doesn't mean CFML is good or "bad", it just means it got one thing right which makes it nice to use in certain cases. All languages have these nice things, including Perl and PHP (though I haven't worked with Perl in a decade, so that's not firsthand knowledge of course).

Comments are always wrong. Or become that way the moment the second pass is made on the code.

This IS a problem with Perl ... so much is inferred behind the scenes, side effects and the like. Even if you're used to the language it can be hard to keep track of all the hidden state. That just doesn't happen as much in most other languages.

I'm no bigot, and I use Perl often. But clearly-written code is always better than commented code, especially as it ripens with age. Perl does make that tougher to do.

Sean,

Again I disagree. Any source code can become poorly maintained and unclear. It is not the language's fault if a programmer does not refactor her code for clarity, simplicity, and readability. Self documenting code is much easier in languages like Perl, which resemble natural language closely.

Casey, are you saying that:

* idioms like "<>" and "$_"
* the fact "@foo" and "$foo" mean different things
* that "sub" doesn't get passed named params
* a hacky, half-assed implementation of OOP
* etc.

aren't "the language's fault"?

Yes, you can write sloppy code and lucid code in almost any language. That's not the point.

Perl's "features" make it harder to write code that's easy to read.

It's be one thing if you said that those legibility tradeoffs were worth it for the added convenience. Or, perhaps, you could say that Tim Bray's work is not an accurate example of Perl's shortcomings. But the fact you deny Perl's design compromises makes it hard to take you seriously.

First bullet point should be:

* idioms like "<>" and "$_"

Joe,

I don't believe your points are legibility trade-offs, with the possible exception of the OO semantics. I do not like bondage and dicipline programming. Perl's power is derrived from its flexibility.

Frankly, I'm finding it hard to take lazy programmers seriously. They complain when Perl allows them to be lazy (or to not *need* to know any better). Just because Java and Python don't "encourage" you to be lazy doesn't mean you can't be.

Going back to your bullet points, 1-3 are all *features*. Number 3 will be a sticking point with some, but it's important to remember that there are efficient, readable ways to get named parameters (and lots of them, another feature).

Please, if you see bad Perl code, don't blame the language. It was the programmer who was lazy.

If you are lazy and it comes to bite you, perhaps you want Java or Python. Just remember that they don't enforce good OO principles, modular code, removal of duplication, or good documentation either.

Perl is a write only language. Even a good perl programmer has trouble reading another one's code. The slogan of perl TMTOWTODI (There's more than one way to do it) is both perl's greatest strength and weakness.

True, perl makes easy things easy and hard things possible, but I just hate reading perl source code.

Perl makes it easy: Try whipping up a Java Program to process a half million records where the 4th field must be remapped from M to 1 and F to 0. With perl, you can be up and running in a very short time. Java suddenly feels very heavy and bulky.

On the other hand, open up a perl script you have not looked at in a while and try to remember what these mean: $', $!, $#, $%, $(, $*, $,, $:, $?, $[, $], $/, $;, $@, $\

or try to remember exactly how this line of code works in the below snippet. Not very intuitive in my opinion.
$count{$_}++; # count each separate word

It just does not make sense to a reasonable logical person. It looks like line noise. The extra effort you spend decrypting the source code becomes a burden.

Maybe I am just bitter because I can't remember these builtins very well and need a cheatsheet at all times whereas in other languages I don't need a cheatsheet.
----------------------------------------------
# Analyze words in the input file or files
while (>) {
foreach (split) { # break $_ into words, assign each to $_ in turn
$total++;
next if /\W/; # strange words skip the remainder of the loop
$valid++;
$count{$_}++; # count each separate word
## next comes here ##
}
}

print "total things = $total, valid words = $valid\n";
foreach $word (sort keys %count) {
print "$word was seen $count{$word} times.\n";
}

Jeremy:

Totally offtopic, but when we type the symbols "less-than" and "greater-than" next to each other, why does the "less-than" disappear?

(The "greater-than" is correctly encoded to &gt;)

Should be a trivial bugfix, no?

Hillary,

First, intuitive *is* opinion.

Second, you have seen far too much code written by bad programmers. Sadly, bad programmers are easy to come by.

Perhaps you're right. Perl has a low learning curve, but once you've learned the idioms you use them. That makes Perl code written by experienced programmers harder to follow by the novice.

This is still no different than C, or C++, or even Java and Python.

I don't think the problem with the code is lack of comments as much as bad variable naming. It's the same with the sample code you posted Hillary, although it's compounded by using $_ in two different scopes which is misleading and lazy; I'd use 'foreach my $word ( split /\s/, $_ )' -- suddenly the rest of that loop becomes fairly readable.

FWIW, Tim's code rewritten with some better names is on my site.

That's it, I'm finished. I'm dumping Perl in favor of Brainfuck. Perl is just too legible. I only want one way to do it, gosh darn it, and I want it as incomprehensible as possible.

It is not the language's fault if a programmer does not refactor The code