Xref: utzoo comp.lang.c:27164 comp.lang.misc:4625
Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!uunet!mcsun!ukc!icdoc!inmos!mph@lion.inmos.co.uk
From: mph@lion.inmos.co.uk (Mike Harrison)
Newsgroups: comp.lang.c,comp.lang.misc
Subject: Re: A note for those not consumed by efficiency worries
Message-ID: <4880@ganymede.inmos.co.uk>
Date: 23 Mar 90 12:59:53 GMT
References: <1990Mar21.061420.9862@athena.mit.edu> <1990Mar21.163413.10711@aqdata.uucp> <1990Mar22.072712.10902@diku.dk>
Sender: news@inmos.co.uk
Reply-To: mph@inmos.co.uk (Mike Harrison)
Organization: INMOS Limited, Bristol, UK.
Lines: 29

In article <1990Mar22.072712.10902@diku.dk> jensting@skinfaxe.diku.dk (Jens Tingleff) writes:
>sullivan@aqdata.uucp (Michael T. Sullivan) writes:
> ...
>Quite right. I always repeat to myself, whenever I'm urged to do an
>unmotivated source code ``optimisation'', 
>
>	MAKE THE THING WORK, THEN MAKE IT FAST.
>
The formulation of this rule that I always use is:

"It is easier to make a correct, slow program run fast than to make a fast,
wrong program run right".


On the subject of rules, I once saw this one in a book:

  "The first law of system design : 

       Never check for an error condition that you don't know how to handle!"

This sounds like the fruit of bitter experience.

Mike,


Michael P. Harrison - Software Group - Inmos Ltd. UK.
-----------------------------------------------------------
UK : mph@inmos.co.uk             with STANDARD_DISCLAIMERS;
US : mph@inmos.com               use  STANDARD_DISCLAIMERS;