A note for those not consumed by efficiency worries

[Ed Nilges]

In article <15286 at bfmny0.UU.NET>, tneff at bfmny0.UU.NET (Tom Neff) writes:

>I.      Code it portably and soundly.
>
>II.     Identify the places where the CPU wastes most of its time.
>
>III.    Replace those sections, CONDITIONALLY if possible, with less
>        portable, faster code.
>
It needed to be said: thank you for saying it.  Niklaus Wirth sounded
a note of sanity at the 1987 ASPLOS conference when he appealed to
an unsympathetic audience of microefficiency-obsessed RISC designers
for reliability and APPROPRIATE efficiency.  Obsession with "efficiency"
at the cost of reliability is not limited to hardware design (indeed,
hardware designers seem to have a greater loyalty to basic reliability
than software designers).

If efficiency is important and reliability is not, here is the greatest
program in the world.  It looks trivial, but I tested it and it seems
to work.  It's even got a comment to tell what it is.


     /***** The greatest program in the world *****/
     main()
     {
     return;
     }


Although the program does not appear to meet the specifications of the
project that a given programmer may be working on at present, if re-
liability truly does not matter then the above program is the allpurpose
panacea (for somewhat the same reason that n*0 is 0 for any n).
It's also guaranteed not to upset the user by having features
he doesn't like.  It's the worlds first Taoist program, for "it is
in non-action that we discover the mysterious beginnings of the
universe".

That was a joke ((-8), but long ago Gerald Weinberg told a story
(in his THE PSYCHOLOGY OF COMPUTER PROGRAMMING, Van Nostrand Reinhold
1971) of a young programmer who had a slightly "inefficient" table-
driven solution to a problem in automotive manufacture: determining
if a given combination of options was feasible.  When challenged on
the "inefficiency" of his solution, the programmer replied with a
variant of the above program.  The "efficient", non-table-driven
program (which was rife with bugs) didn't work.  Therefore, correct-
ness was not a necessity and the above "do-nothing", Taoist program
was even better...because it is more efficient!

>Every good programmer KNOWS this works, and saves time in the long run.
>That's precisely why some programmers HATE it, and waste words railing
>against it.  It's like eating your vegetables.  Programming, as a field,
>does not venerate vegetable eaters. :-)

It is gradually becoming worse in this regard as it is "rationalized":
as we get more and more MBAs and MSCSs and fewer good programmers.
(Note: yes, you CAN be a good programmer and have an MSCS, or even
an MBA...so turn those flamethrowers off.)

Soon we'll be as "efficient" as the American auto industry, where
a simple procedure for avoiding rust (E-coat) was rejected by the
Big Three for years until finally Japanese competition forced their
hand.  E-coat wasn't an "efficient" way of building a car since it
involved one extra step: it was more "efficient" to make the driver
(who was, twenty years ago, at the mercy of Detroit) spend hundreds
of dollars at Ziebart or Rusty Jones (in dark moments, this reminds
me of the RISC philosophy: make the compiler writer do all the work).
>
>The truth is that the squeaky wheel gets the grease, -or- no news is good
>news.  The programs out there that are written RIGHT and optimized RIGHT
>are the ones you never hear about, because they don't make news, they
>just WORK.

...and the poor programmers get "consulting" assignments, at 40 bucks
an hour, fixing bugs they coded at their former jobs.  It's a
wicked world.