In message FDF50905-05A3-11D7-81B8-003065B4F3AC@bigpond.net.au Karl Goiser kgoiser@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