EGNILGES@pucc.Princeton.EDU (Ed Nilges) (03/29/90)
In article <15286@bfmny0.UU.NET>, tneff@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.