Perl is worse!

[Eric Lorenzo]

grey at despair.rpglink.com (Steve Lamb) writes:
> On 28 Jul 2000 12:49:57 -0400, Eric Lorenzo <zo at angband.org> wrote:
> >But communication with the *computer* isn't actually the primary
> >purpose of typing.  Rather, typing is a means for programmers to
> 
>     Funny, I thought that was what comments were for.  

Somehow, I knew you'd say this, but my previous message was already
too long, so I didn't include a preemptive rebuttal.  That said, there
are a number of reasons why comments are an inferior solution for many
problems like the one we're dealing with here:

1) They can be ambiguous - after all, they're written in natural
   language.

2) Heavy commenting can make a program much harder to read, by
   making it harder to pick out actual code, and obscuring overall
   block structure.

3) When a programmer uses comments to communicate in the way you
   recommend, he ends up having to keep two versions of the same
   information in sync: the code for the compiler/interpreter,
   and the comments for other programmers.  So now when you modify
   code, you've got the extra bookkeeping of changing comments as
   well.  How exactly is this easier than simply adding or removing a
   call to 'int()' around the input string?

4) They can be wrong: It's not uncommon for a programmer to change
   code and *not* update comments to match.  Particularly when in a
   hurry.  And particularly in cases where the code doesn't actually
   change, only the programmer's expectation of what it will do (cases
   which the implicit type coercions you love will allow to come up
   much more frequently).  Even when the programmer *does* make the
   effort to keep comments in sync, he may be wrong in what he thinks
   a particular piece of code will do.

This isn't to say that one should avoid comments entirely, but rather
that one shouldn't treat them as a panacea.  I mostly limit my
comments to docstrings at the start of a module, class, or function,
and their purpose is only to provide an overall description of the
purpose of the code I'm commenting.  At this high level, ambiguity
isn't such a problem, and the overall purpose of a module, class
doesn't change much, so keeping the code and the comments in sync is
no problem.

For little details like what form I expect a particular user input to
take, the terser and less ambiguous of the language provide a superior
solution.  And it provides other advantages, like making it far more
likely that bad input will generate a visible error right away, rather
than down the road in some part of the program that isn't clearly
related to the point where the bad data entered the system.  This can
drastically simplify debugging.

Eric