But it's his own lack of any comments that confused his co-worker. If the code isn't intuitive, document it.

Come on Tim, don't you know better? Don't blame the language. You can write obscure code and leave it undocumented in any language.

Posted by jzawodn at July 31, 2003 05:55 PM

Reader Comments
# Jim said:

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.

on July 31, 2003 07:07 PM
# Bill said:

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

What's a good one then?

on July 31, 2003 07:21 PM
# Casey West said:


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.

on July 31, 2003 07:31 PM
# Mike Hillyer said:

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.

on July 31, 2003 07:55 PM
# Jeremy C. Wright said:

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

on July 31, 2003 08:15 PM
# sean said:

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.

on July 31, 2003 10:25 PM
# Casey West said:


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.

on August 1, 2003 06:32 AM
# Joe Grossberg said:

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.

on August 1, 2003 09:12 AM
# Joe Grossberg said:

First bullet point should be:

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

on August 1, 2003 09:15 AM
# Casey West said:


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.

on August 1, 2003 11:54 AM
# Hillary Rosen said:

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
next if /\W/; # strange words skip the remainder of the loop
$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";

on August 1, 2003 01:09 PM
# Joe Grossberg said:


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?

on August 1, 2003 01:21 PM
# Casey West said:


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.

on August 1, 2003 01:23 PM
# Chris Winters said:

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.

on August 1, 2003 11:20 PM
# Wee said:

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.

on August 4, 2003 02:18 AM
# Fred Hurb said:

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

on September 29, 2003 07:13 AM
Disclaimer: The opinions expressed here are mine and mine alone. My current, past, or previous employers are not responsible for what I write here, the comments left by others, or the photos I may share. If you have questions, please contact me. Also, I am not a journalist or reporter. Don't "pitch" me.


Privacy: I do not share or publish the email addresses or IP addresses of anyone posting a comment here without consent. However, I do reserve the right to remove comments that are spammy, off-topic, or otherwise unsuitable based on my comment policy. In a few cases, I may leave spammy comments but remove any URLs they contain.