Path: news.eternal-september.org!eternal-september.org!feeder3.eternal-september.org!panix!.POSTED.spitfire.i.gajendra.net!not-for-mail
From: cross@spitfire.i.gajendra.net (Dan Cross)
Newsgroups: alt.folklore.computers,comp.os.linux.misc
Subject: Re: The joy of FORTRAN
Date: Wed, 5 Mar 2025 02:59:05 -0000 (UTC)
Organization: PANIX Public Access Internet and UNIX, NYC
Message-ID: <vq8elp$q3f$1@reader1.panix.com>
References: <59CJO.19674$MoU3.15170@fx36.iad> <vB5xP.126521$eNx6.22176@fx14.iad> <vq2scj$144$1@reader1.panix.com> <vq7lan$1h28q$1@paganini.bofh.team>
Injection-Date: Wed, 5 Mar 2025 02:59:05 -0000 (UTC)
Injection-Info: reader1.panix.com; posting-host="spitfire.i.gajendra.net:166.84.136.80";
	logging-data="26735"; mail-complaints-to="abuse@panix.com"
X-Newsreader: trn 4.0-test77 (Sep 1, 2010)
Originator: cross@spitfire.i.gajendra.net (Dan Cross)

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.