Re: The joy of FORTRAN

In article <vq7lan$1h28q$1@paganini.bofh.team>,
Waldek Hebisch <antispam@fricas.org> wrote:

In alt.folklore.computers Dan Cross <cross@spitfire.i.gajendra.net> wrote:

In article <vB5xP.126521$eNx6.22176@fx14.iad>,
Charlie Gibbs  <cgibbs@kltpzyxm.invalid> wrote:

[snip]
Oh, and anyone who modifies code without updating the
corresponding comments to reflect the change deserves
some sort of nasty punishment.  Maybe we can make them
maintain any other programs whose comments have become
outdated and misleading.

 
John Ousterhout recently published the contents of a written
"debate" he had with Robert C Martin that went into this at some
length.  With the caveat that I think Martin is a charlatan,
folks here might find it interesting and relevant.
 
https://github.com/johnousterhout/aposd-vs-clean-code/blob/main/README.md

>
I read large part of this tekst.  I fully agree with John's
critique of decomposed PrimeGenerator.  Personally I find
the Knuth-based pre-decomposed version the clearest one:
- it is obviously correct once one gets loop invariants
- it is compact enough that loop invariants can be easily guessed.
>
I was able to understand this version in few minutes.  Reference
to Knuth helped, because first (decomposed) version looked like
a monster which raised serious doubts about correctness and
efficiency, Knuth name assured me that this may be worth looking at.
I have some interest in generating primes and it is possible that
I saw this method before.  Certainly I did not remember it.

In fact, the problems with Martin's version were even worse than
what John pointed out; a few I found, others I saw on reddit or
hacker news.

Briefly, Martin's program fails to check its input and will
throw an exception due to an out-of-bounds array access for n<1.
It will also do that for n<2, which means that his version
cannot be used to return a list that contains only the first
prime.  Furthermore, in his relentless drive to decompose into
arbitrarily smaller functions, he scatters state around a class,
but he stores it in static class members, meaning that his
implementation is not thread safe.  Also, he stores the squares
of primes into an array eagerly, as he finds each prime; but
once primes exceed 2^16, this will overflow the value in his
prime multiples array.  In the original algorithm (acutally due
to Dijkstra, not Knuth), they were only added to the prime
multiples array when necessary.

So more remarks: testing divisibility only by numbers smaller or
equal to square root of candidate is standard obvious trick.
I it not clear how long it would take me to invent such thing,
but I saw it long ago and once I saw it it was obvious.
>
I correctness of John's version is more tricky: we should
increase number of primes used for testing once candidate
becoms equal to square of next prime.  John uses different
looking condition and gives no justification that it is
equivalent to the correct one.
>
Part of the comment
>
:       // ..........................(all elements after this are greater
:       // than our current candidate, so they don't need to be considered).
>
is misleading: those elements are greater then _square root_ of
the candidate.

Yes.  John's version had some problems; not as many as Martin's
version, but then again John is actually competent, while Martin
is a charlatan and a blowhard.

Concerning comments I am mostly on Martin's side.  More precisly,
interfaces should be precisely specified.  In some cases (like
math problems) code implements "well known" functions and then
there is not much to say (but things like limitations on arguments
and precision should be spelled out).  In other cases one needs
to define appropriate terms and give more detail.  OTOH
implementation in many cases needs no comments.  In other case
one may want rather extensive description of method/algrorithm/
data structures.  IMO extensive description if best provided
in a separate document.  In case of standard algorithms one
can simply add reference to the literature.  If something is
non-standard (new), then there should be a document describing
it.  My point is that comment is not good place to put such
extensive description (for example there are typographic
restrictions) and, once person is familiar with the problem
large block of comments is only a distraction.  Also, I have
much more faith in estabished texbook or paper in peer reviewed
journal, then in comments which frequently say a lot about
lack of understanding of person writnig the comment and only
a little about actual problem.  There are cases when comments
are worthwile, but they are relatively infrequent.  In particular
in modern times we have a lot of trivial code and when we
come to something nontrivial it is frequencly so complex that
one can not reasonably explain it in a comment.

I came with a version that I liked somewhat better, and sent it
along with a rather lengthy email to John's mailing list.  No
one has responded, however, so I fear it was not well received.

- Dan C.