🚀 go-pugleaf

In article <721539025@sheol.UUCP> throopw@sheol.UUCP (Wayne Throop) writes:
>: From: rh@smds.com (Richard Harter)
>: Message-ID: <1992Nov11.100555.4706@smds.com>
>: What Bob is telling you is that there are problems
>: which are so computationally demanding that computational efficiency is
>: far more important than standard programming style guides. 

			...................

>: There is a price for programming for clean code;
>: in most cases the benefits far outweigh the price; sometimes they don't.

There is a price for programming in what the languagists think is clean code.
Nobody except a computer programmer can read it at all!  Now I received some
email from someone about the algorithm I posted in which he asked for another
copy of the code where the control-path was "clear" and not defined by breaks
or gotos.  Now I do not know how to do that, but analyzing breaks is not that
simple for a human, either.  

>True, but I'm more sympathetic with the Jon Bentley school of
>optimization, where you transform clean, correct code into arcane,
>incomprehensible code by known-safe transforms, and RECORD THE
>TRANSFORMS.  For example, the chapter on code tuning in Programming
>Perls, especially the case study of the binary search.  Or, if I'm
>remembering rightly, Bentley's book Writing Efficient Programs.  Of
>course, the shortcoming in this context is that the central focus isn't
>really numerical problems, but I regard that as relatively minor. 

We still have the problem of what is comprehensible to whom.  And what 
is one supposed to do if the hardware operations wanted are not even
expressible in the language?  Sure, one can simulate them, but nobody
will be able to read THAT code.
-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
Phone: (317)494-6054
hrubin@snap.stat.purdue.edu (Internet, bitnet)  
{purdue,pur-ee}!snap.stat!hrubin(UUCP)