On Monday, December 2, 2002, at 06:02  Uhr, Tim Rowledge wrote:

> 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'.

Well, patterns are a step in the process, but other steps need to 
follow, which is what I was saying.  When you identify the pattern, you 
see the potential for a standard part.  You then need to formalize that 
standard part and put it in your library.  If this turns out to be 
difficult/impossible, and you therefore have to repeatedly implement 
this pattern, then you know that your means for expressing abstractions 
is obviously not good enough, because it didn't allow you to capture 
the relationships expressed in the pattern.

> Patterns are a small part of recognising that there are standard ways 
> to
> do things and you shouldn't fuss about smaller details.

Exactly, except that patterns do force you to fuss the small details, 
and that is what is being criticized.

>  _Real_ engineers
> do not make each nut and bolt individually.

Exactly.

>  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.

No, patterns are *not* standard parts.  They are descriptions of how 
you can make your own custom part of a specific kind.  So instead of 
grabbing a part from your bin, you get instructions on how to build 
your own.


>  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.

Exactly.  Each "pattern" has a constant part and a variable part.  In 
software, I should be able to put all of the constant part away in my 
library and only deal with parameterizing it with the variable part.  
Always.  "Design Patterns" are description of recurring "patterns", and 
therefore obviously of parts that haven't been put in the library yet, 
because otherwise they wouldn't recur.

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

Yes.  A procedure captures a pattern of statements, puts it away (by 
name) and allows it to be instantiated/used with parameters.  An object 
captures patterns of data + procedures (though it also does more).  So 
there should be something that "captures" the current level of 
"patterns", and it turns out that there are mechanisms for doing that, 
at least to some extent.  As I  said (and the LISPy gentleman wrote), 
each time you actually see a recurring pattern that you did *not* put 
away, you see that you have a problem...

> 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, that is the problem with standard parts.  However, software has 
the interesting aspect that the parts can be paremeterized.  This is 
not necessarily a perfornance question either, but more often a 
"suitability" question.

>  Yes, you could tweak each component obsessively to what you
> think is perfection but you would make your product utterly impossible
> to afford.

Yes, but that wasn't what was being said, at all.  Quite the contrary, 
in fact.

[More agreement snipped[

Marcel