Python paradigms

[Robert W. Cunningham]

Nick Maclaren wrote:

> In article <Pine.LNX.4.21.0004100757580.19783-100000 at fep132.fep.ru>, Oleg Broytmann <phd at phd.russ.ru> writes:
> |> On Mon, 10 Apr 2000, Robert W. Cunningham wrote:
> |>
> |> > Oleg Broytmann wrote:
> |> > > > python's "and" and "or" operators doesn't evaluate the
> |> > > > second argument unless they really have to...
> |> > >
> |> > >    Yes, I missed that, sorry.
> |> >
> |> > So, it works just fine, right?
> |>
> |>    No. Code is intended not only to beeing run on processor, but also (and
> |> often more important) to beeing read by human. Code is speech, it is the
> |> way to interchange ideas.
> |>    In that sense ugly code is not working even if you add three books of
> |> comments. Code should be readable. Period.
>
> Yes, precisely.  In the real world, programs often have long lifetimes,
> are worked on by many programmers (in parallel and sequentially), are
> sometimes transliterated between languages, and it is common to need
> to modify code which was written 20 years ago by some long-retired
> programmer.
>
> 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.  If a sound and reliable implementation is
possible, then the paradigm is probably a good fit.  Paradigms that encourage "slow" or "fat" code merely to
improve the self-expressiveness of the code is a dubious goal in practical terms, but certainly has value in
abstract terms (i.e., to extract reusable patterns - patterns are *very* expressive).

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.  Many such languages seemed to have come
into existence with the PDP-11 and the Intel 8080, and never migrated far from those platforms.  At times, I was
reduced to staring at assembler dumps to figure out what a line of supposedly "high-level code" was actually
trying to do.  And the code, I was told, had an excellent reputation for being "well written".  It had merely
gotten old, and the original authors had literally died.

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.  Remember, code maintainers are also
"users" of a product, and deserve to have the support of equal documentation.  If the code could do it alone,
I'd say go for it.  But it cannot, and never will.  To believe otherwise is sheer foolishness that displays a
blatant ignorance of how the "real world" works.

The greatest programmers of our age manage to include the equivalent of a "Rosetta Stone" in their work.  It
could be the Weave and Tangle of Knuth's "Literate Programming", or merely inline comments and a good set of
design documents.  But never bare code, all alone.  Never.  A single representation, no matter how elegant,
cannot be sufficient.

Unless, of course, you write code that will never need maintenance: never have a bug, never need a new feature,
never have any other developer than yourself, and your code is used by nobody.  In that case, sure, leave out
the comments!

Computer programming is far more than a form of communication between a programmer and a computer.  It
implicitly involves a virtual army of other people, users and maintainers chief among them.  Remember, the goal
of good communication is NOT "making it possible for another party to understand you".  No, good communication
is "making it DIFFICULT for another party to MISUNDERSTAND you".  Which means, to be understood, you usually
need to say a given thing more than once, in more than one way.  Code is one way.  Comments is another.  They
both (and more) are needed if the source code is to communicate effectively throughout time.

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 the occasional efficient and effective (but(t) ugly) one-liner that saves significant processor time or lots
of code deserves to be commented to death.

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


-BobC