I've just been reading the book "Pattern Hatching: Design Patterns Applied" by John Vlissides, Addison-Wesley 1998, ISBN 0-201-43293-5.
I have come away from this with two overwhelming impressions:
(1) Here is a better than competent OO programmer, and C++ is fighting him every inch of the way.
Example after example is basically "how do I design-hack a way around such-and-such a limitation of C++."
I've always been fairly positive about patterns, and I've taught them to students. This book, by one of the GoF, made me wonder. The examples strike me as Heath Robinson-ish; is this because of pattern-think, or is it because of C++?
It would be really illuminating to see some of his examples revisited by a better than competent Smalltalker, because I think you'd end up with a completely different set of patterns being applied, or the patterns would look different.
(2) One of the chapters describes the "GENERATION GAP" pattern. The example is a visual interface builder, where you draw your interface and the tool then generates code. "Normally, you can't create a finished, nontrivial application automatically with one of these tools; you have to implement some functionality the old-fashioned way, by hand in a programming language." So GENERATION GAP helps you by doubling the number of classes. (Er, really.)
But WHY do you have to develop part of the interface in one environment (the interface builder) and the rest in another environment? Why shouldn't "what to do when you are pressed" be something you can plug in *and test* in the interface builder?
The answer appears to be "because the interface builder is generating C++" (see point 1 above) "and can't itself run the code it generates".
POOF! An entire pattern disappears up its own fundament if your environment can represent code as data and can run dynamically generated code.
I just wish I understood Morphic better.
Smalltalk: back to the future????
Richard,
It would be really illuminating to see some of his examples revisited by a better than competent Smalltalker, because I think you'd end up with a completely different set of patterns being applied, or the patterns would look different.
I recommend "The Design Patterns Smalltalk Companion" by Alpert, Brown, and Woolf. You can find it online.
Jim
Where? I got some of them but not all at: http://scgwiki.iam.unibe.ch:8080/SmalltalkWiki/18
I recommend "The Design Patterns Smalltalk Companion" by Alpert, Brown, and Woolf. You can find it online.
Jim
Jim Menard, jimm@io.com, http://www.io.com/~jimm/
Dr. Stéphane DUCASSE (ducasse@iam.unibe.ch) http://www.iam.unibe.ch/~ducasse/ "if you knew today was your last day on earth, what would you do different? ... especially if, by doing something different, today might not be your last day on earth" Calvin&Hobbes
On Wednesday, November 27, 2002, at 03:51 AM, Stephane Ducasse wrote:
Where? I got some of them but not all at: http://scgwiki.iam.unibe.ch:8080/SmalltalkWiki/18
Sorry, I should have said, "buy it online", not "find it online". I don't know if the book's text is available online.
Jim
On Tuesday 26 November 2002 07:25 pm, Richard A. O'Keefe wrote:
I've just been reading the book "Pattern Hatching: Design Patterns Applied" by John Vlissides, Addison-Wesley 1998, ISBN 0-201-43293-5.
I have come away from this with two overwhelming impressions:
(1) Here is a better than competent OO programmer, and C++ is fighting him every inch of the way.
Luckily (?), he's now working mostly on Eclipse plugins (at least that's what he told me on the monorail at OOPSLA).
Example after example is basically "how do I design-hack a way around such-and-such a limitation of C++."
Yes, but the original Design Patterns book was like that too. There are patterns in there that are trivial or unnecessary in Smalltalk.
I've always been fairly positive about patterns, and I'vetaught them to students. This book, by one of the GoF, made me wonder. The examples strike me as Heath Robinson-ish; is this because of pattern-think, or is it because of C++?
(Note to some US readers: Heath Robinson did drawings similar to Rube Goldberg)
Don't you think that (for instance) the C++ template system and especially its (excessively?) clever use by the STL rates as a more than a bit Heath Robinson-ish?
It would be really illuminating to see some of his examples revisited by a better than competent Smalltalker, because I think you'd end up with a completely different set of patterns being applied, or the patterns would look different.
Or some wouldn't be there, as you note:
POOF! An entire pattern disappears up its own fundament ifyour environment can represent code as data and can run dynamically generated code.
Is this something that would be interesting/useful for your students?
"See how patterns only make sense in their original (often unstated) context: watch how I make this one go away by a different language choice..."
Hi Richard!
On Wednesday, November 27, 2002, at 04:25 Uhr, Richard A. O'Keefe wrote:
I've just been reading the book "Pattern Hatching: Design Patterns Applied" by John Vlissides, Addison-Wesley 1998, ISBN 0-201-43293-5.
I have come away from this with two overwhelming impressions:
(1) Here is a better than competent OO programmer, and C++ is fighting him every inch of the way
Well, that's C++ for you ;-)
Example after example is basically "how do I design-hack a way around such-and-such a limitation of C++."
That's the impression the GoF book made on me.
I've always been fairly positive about patterns, and I've taught them to students. This book, by one of the GoF, made me wonder. The examples strike me as Heath Robinson-ish; is this because of pattern-think, or is it because of C++?
Both!
It would be really illuminating to see some of his examples revisited by a better than competent Smalltalker, because I think you'd end up with a completely different set of patterns being applied, or the patterns would look different
You get fewer patterns, but still too many.
(2) One of the chapters describes the "GENERATION GAP" pattern. The example is a visual interface builder, where you draw your interface and the tool then generates code. "Normally, you can't create a finished, nontrivial application automatically with one of these tools; you have to implement some functionality the old-fashioned way, by hand in a programming language." So GENERATION GAP helps you by doubling the number of classes. (Er, really.)
But WHY do you have to develop part of the interface in one environment (the interface builder) and the rest in another environment? Why shouldn't "what to do when you are pressed" be something you can plug in *and test* in the interface builder? The answer appears to be "because the interface builder is generating C++" (see point 1 above) "and can't itself run the code it generates".
Well, and because it is generating code in the first place. Interface Builder (NeXT/Apple) doesn't generate code, it creates (and archives) connected object graphs. Code generation is Evil.
POOF! An entire pattern disappears up its own fundament if your environment can represent code as data and can run dynamically generated code.
Yes! IMHO, ALL patterns are like this. Think of it: why should there be repeating patterns of code in our programs? There shouldn't be! If there is a "pattern", we should be able to somehow express the pattern and encapsulate it. "Once and Only Once".
So I consider a pattern a bug. Not a bug in the program, but a bug in the programming language. Or let's call it a shortcoming, because the language cannot encode this pattern in a way that I can put it in a library and forget about it. I think the fact that many patterns necessary in a primitive language ( C++, Java ) are not necessary for their more advanced predecessor (Smalltalk) supports this point of view. However, we shouldn't be too smug: the Smalltalk Pattern Companion is not empty. In an ideal world / programming language, there would be no patterns books.
There is some reason to believe that such an ideal world may be even theoretically impossible, or at least impractical, but that doesn't mean we shouldn't treat patterns as indicators of something being wrong.
Marcel
Hi Marcel et al,
It is interesting that you should write about patterns in this way.
I was reading some 'propaganda' about Lisp some time ago on Paul Graham's web site and the following quote really made me sit up and take notice: "When I see patterns in my programs, I consider it a sign of trouble. The shape of a program should reflect only the problem it needs to solve. Any other regularity in the code is a sign, to me at least, that I'm using abstractions that aren't powerful enough-- often that I'm generating by hand the expansions of some macro that I need to write."
(The whole article can be found at: http://store.yahoo.com/paulgraham/icad.html)
This is very similar to the way you describe it and I can't help but come to the conclusion that "patterns" is taking programming down the wrong path!
Regards,
Karl
On Sunday, Dec 1, 2002, at 20:52 Australia/Tasmania, Marcel Weiher wrote:
Yes! IMHO, ALL patterns are like this. Think of it: why should there be repeating patterns of code in our programs? There shouldn't be! If there is a "pattern", we should be able to somehow express the pattern and encapsulate it. "Once and Only Once".
So I consider a pattern a bug. Not a bug in the program, but a bug in the programming language. Or let's call it a shortcoming, because the language cannot encode this pattern in a way that I can put it in a library and forget about it. I think the fact that many patterns necessary in a primitive language ( C++, Java ) are not necessary for their more advanced predecessor (Smalltalk) supports this point of view. However, we shouldn't be too smug: the Smalltalk Pattern Companion is not empty. In an ideal world / programming language, there would be no patterns books.
There is some reason to believe that such an ideal world may be even theoretically impossible, or at least impractical, but that doesn't mean we shouldn't treat patterns as indicators of something being wrong.
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
On Sun, Dec 01, 2002 at 09:02:54PM -0800, Tim Rowledge wrote:
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...
Not so surprising, really. You chose to spend those 20 years working on something scalable and designed to support higher level abstractions. That means that there is some small chance that your efforts will not have been entirely discarded ten years hence. It sounds like a reasonable engineering choice to me ;-)
By the way, I would hope that the transition to higher level software abstractions (patterns, etc) would have happened regardless of increases in computational power. If anything, I suspect that the constant improvement of computer hardware may have slowed things down, as it has encouraged people (and corporations, and schools) to repeatedly re-implement the same old ideas, often poorly, and often without appreciating that it was just the same old stuff.
This coming from someone who thinks it's entertaining to re-implement old unix command shells. Go figure.
Dave
"David T. Lewis" lewis@mail.msen.com wrote:
On Sun, Dec 01, 2002 at 09:02:54PM -0800, Tim Rowledge wrote:
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
Personally I don't think the absence of a "parts" industry in software has much to do with computer speed etc. I think Brad Cox idea about this problem is correct:
Search down to "ATOMS VERSUS BITS" on: http://virtualschool.edu/cox/pub/97IEEE/
I haven't read much of Brad's work but this part has stuck with me - the absence of mass in software strikes me as a fundamental difference compared to the rest of the industry.
On the other hand I don't think Brad's "proposed solutions" like his ideas on micropayments etc are any good. But that doesn't stop his analysis of he problem from being correct. :-)
regards, Göran
PS. I discussed this in part, especially regarding the "death" of the software tools market, with David Simmons at OOPSLA over a few beers but we didn't really have the same views.
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
On Monday, December 2, 2002, at 04:13 Uhr, Karl Goiser wrote:
Hi Marcel et al,
It is interesting that you should write about patterns in this way.
I was reading some 'propaganda' about Lisp some time ago on Paul Graham's web site and the following quote really made me sit up and take notice: "When I see patterns in my programs, I consider it a sign of trouble. The shape of a program should reflect only the problem it needs to solve. Any other regularity in the code is a sign, to me at least, that I'm using abstractions that aren't powerful enough-- often that I'm generating by hand the expansions of some macro that I need to write."
(The whole article can be found at: http://store.yahoo.com/paulgraham/icad.html)
This is very similar to the way you describe it and I can't help but come to the conclusion that "patterns" is taking programming down the wrong path!
Yes, it sounds almost the same. My diploma-thesis (from 1997) also has a couple of things to say about patterns:
http://www.metaobject.com/papers/
Marcel
squeak-dev@lists.squeakfoundation.org
-
David T. Lewis -
goran.hultgren＠bluefish.se -
Jim Menard -
Karl Goiser -
Marcel Weiher -
Ned Konz -
Richard A. O'Keefe -
Stephane Ducasse -
Tim Rowledge