In message <FDF50905-05A3-11D7-81B8-003065B4F3AC at bigpond.net.au>
          Karl Goiser <kgoiser at bigpond.net.au> wrote:

> Hi Marcel et al,
> 
> It is interesting that you should write about patterns in this way.
[snippety-snip]
>From the perspective of a mechanical engineer and industrial designer
(and you lot thought I was a software weenie!) patterns are the barest
beginnings of a glimmer of hope that one day the words 'computer' and
'science' might belong in a sentence together that doesn't also include
'no such thing'.

Patterns are a small part of recognising that there are standard ways to
do things and you shouldn't fuss about smaller details. _Real_ engineers
do not make each nut and bolt individually. We do not try to reinvent
every little item in a product. We combine standard parts
(patterns) whenever possible and trust them to behave as specified. We
use building codes and ASME codes (patterns) etc etc to avoid innovation
whenever posible. Innovation is expensive, risky, and requires way too
much work to be worth the hassle when dealing with trivia. Save the
skull-sweat for important parts, like the point of the product.

Funnily enough, OOP is another small aspect of this. Which is why I've
always considered Smalltalk the natural language of engineering.

The downside of this is that every item produced in this manner is
decidedly sub-optimal. Bolts are a little larger than is really needed,
bearings are a bit over rated, beams are a little stronger than is truly
required. Yes, you could tweak each component obsessively to what you
think is perfection but you would make your product utterly impossible
to afford.  The nearest that engineers ever get to doing this is in
motor racing and maybe, just maybe, space vehicles although in both
cases many many standard parts are still used.

Until recently it has been possible to argue against standard parts in
software because computers were too slow to make anything other than
minutely tweaked code to do any useful job. I rather think that that
time has passed and we should admit that in a time of 400 mip handheld
machines with 64Mb of ram that we should be concentrating on the quality
of what they do rather than almost solely on the speed with which they
screw up. A long time ago, Dan Ingalls (I think - maybe Larry Tesler?)
was quoted as saying
	"We have reached the point of computational affluence where
	we should consider the quality of cycles rather than the
	number of them".
Or something very like that.

All of which sounds pretty amusing from someone that has spent the last
twenty years woking on making Smalltalk faster...

tim
-- 
Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
Fractured Idiom:- HASTE CUISINE - Fast French food