"Design Patterns" Aren't
perl.plover.com
perl.plover.com
I agree, though, that the most interesting aspects of Alexander never made it into GoF. His key insight is that buildings should be designed around what makes humans feel more alive in them. Applying that to software, you'd end up thinking more about projects and teams than about iterators or singletons.
Another aspect of Alexander that's relevant to programming is his exploratory approach to making buildings. As I understand it, he never designs anything up front. Rather, he studies the site, talks to the people, and builds a little at a time, allowing the thing to emerge in a way that is appropriate.
No - I think you would end up thinking more about the end users of your applications.
Of course he blames the misunderstanding on the readers (who else?), but it interesting example for anyone concerned with presentations or communication in general to ponder why this happens in this specific presentation.
Um, because in 2002 your presenter skills sucked and you included pages 4, 5, 6 which weren't supportive of your real point.
Also, because of the nice goat picture the one thing everyone will remember is page 6 and that "the C++ macro system blows goat dick".
Making your most memorable point be one that isn't what you're trying to convey is fail.
It's one of a few books that I've checked out of the library a couple of times, only to end up buying it. (Last time I moved, I had something like 30 boxes of books...I sold more than half of them to Half Price Books, and promised myself that I do not buy books anymore. But some books are just mandatory.)
If you're going to trash something, at least know enough about it to be able to describe what you're trashing.
I agree with the author that thinking about design is where we all want to go. Re-usable bits of pre-digested thinking is crap. But with generics you can do container-iterator stuff pretty easily in most modern languages. His examples and his understanding of where languages were is sub-standard, even for 2002. ("when we're talking patterns everyone knows we mean C++" -- WTF?)
But that's just the technical stuff that he rapidly dismissed in his update/addendum. Fine. I still think he doesn't get it. I think he's right that patterns are largely about vocabulary, but he's wrong to say that the GoF book (or patterns in general) turn people into macro processor systems. I have yet to read the GoF book, but my basic understanding of patterns is that it indeed creates vocabulary - which gives you abstractions with which to glue your thoughts together so you can have new thoughts. That's what vocabulary does. That's exactly how I think of design patterns in software.
You're doing it wrong. You criticize a criticism after you've read the topic of the criticism, not before. Subtle difference, I know, but worth keeping in mind.
What the author's saying: Alexander did not mean something like the GoF Design Patterns, so maybe we should look at Alexander's book again?
( * - He originally meant it to be something like the OLPC operating system.)
* People are using 1970s-era languages
* The "Design Patterns" solution is to turn the programmer into a fancy macro processor
* Christopher Alexanders design patterns are a valuable concept which might benefit computer programming.
* But GoF patterns sucks and has nothing to do with Alexanders patterns
Too bad he doesn't provide any kind of example of how Alexander-type patterns could be applied to programming. Otherwise it might have been a quite interesting presentation.
It's no wonder that Patterns in each discipline should vary so widely.
As different from each other as they are from 1920s Stitching Patterns sold in catalogs with bulk cloth.