On Monday, December 2, 2002, at 06:02 Uhr, Tim Rowledge wrote:
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'.
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