Python paradigms

[Nick Maclaren]

"Robert W. Cunningham" <rcunning at acm.org> wrote:
>
> > At best, confusing code wastes effort.  At worst, it causes mistakes
> > to be introduced.  I have seen the latter effect many times.
> >
> > That is why I was talking about the benefits of those paradigms for
> > code clarification, and neither efficiency nor compactness.  Python
> > has some very useful facilities, but is a bit tedious for some kinds
> > of scripting.
> 
> Again, comments in the code can cover all these bases.  A good
> "paradigm" is a good thing to have, but it is no Holy Grail.  It is but
> one step in the creation of a good program.  ...

Your second sentences are correct, but your first is most definitely
false.  Dangerously so.  I would be the last person to agree with that
nonsense that any languages or programming styles are "self commenting",
but the converse is equally wrong.  Using unclear paradigms (whether
out of 'cleverness' or because the language forces you to) has the
following major problems:

    1) It makes it very hard to see when your code does not match your
intent.  I have frequently had arguments with people who have taken
your viewpoint, when I have pointed out that the code that they wrote
only SEEMS to match their comments!  Typically, the error is that it
does so, except for a few, nasty boundary cases.

    2) Code rot.  In the days of punched cards, only a few programmers
maintained their comments.  Nowadays, most do, but a large number tend
to cut corners when adding a 'simple' modification to trap a previously
unthought-of boundary condition (see above.)  And have you every tried
to get a large vendor to accept a bug report on a COMMENT when the code
works correctly?

    3) It is very hard to express the sort of details that cause
trouble in English - comments are good at saying WHAT should be done
but not so good at saying EXACTLY HOW.  This is best done in a pseudo
mathematical language, such as a programming language - which is, after
all, precisely what ALGOL 60 was designed for!

> Have any of you ever had to port a product written in a "dead" computer
> language?  I have, more than once.  The comments were the ONLY thing to
> make the task possible, since even texts adequately documenting the old
> languages (especially the libraries) were extremely difficult to find.

Not often - probably only a few dozen times on sizeable codes.  In the
cases that I had too look at in detail, things broke down something like
the following (all figures being wildly incorrect):

    75%    comments and code matched, and either was clear enough
    15%    comments and code matched, but both were inadequate
     5%    comments and code didn't match, and the code was correct
   2.5%    comments and code didn't match, and the comments were
   2.5%    I gave up, and reimplemented from my own algorithm!

> Human language, written well, is far more expressive than computer
> languages.  That's why computer hardware and software is documented with
> books, and not in their "own" languages.  ...

Not so.  They are written that way 'for simplicity' (i.e. because it is
quite hard to get most people to read mathematics as a specification)
and because there are no standardised languages for expressing the
semi-mathematical concepts.  However, when specifying things like
library functions, they very often ARE specified in terms of an
'example implementation' - i.e. in their own languages.

> At best, sound paradigms can simplify code and reduce the level of
> commenting needed, but can in no way eliminate the need for thorough
> commenting and other documentation.

And conversely.

> And if you can't write good comments, how can you POSSIBLY believe you
> can write good code?

And, if you can't say what you mean in a semi-precise language like
a programming language, how are you going to do it in English?


Regards,
Nick Maclaren,
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QG, England.
Email:  nmm1 at cam.ac.uk
Tel.:  +44 1223 334761    Fax:  +44 1223 334679