I sympathize with the critique of GoF design patterns, but the author is seriously distorting Alexander in his eagerness to dissociate him from them. "How can you distribute responsibility for design through all levels of a large hierarchy" is not the theme of A Pattern Language, which is easy to see when you consider that the book is largely about dwellings (which don't involve any large hierarchies).
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.
I agree that "large hierarchies" may be an overstatement, but it is worth remembering that Alexander does not concentrate total responsibility for the design of a signle in the hands of a single architect, or even a firm of architects, but rather, involves a large number of "end-users"-- and then iterates this notion both upward (to city planning) and downward (to interior design of individual rooms), so while the "hierarchy" may be relatively flat, the problem of distributed responsiblity is a real one (and a relevant one for software).
>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.
No - I think you would end up thinking more about the end users of your applications.
An interesting part is the addendum in the postscript, where he wonders why "almost everyone who has read this has completely missed the point".
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.
He states the answer(but still doesn't see it) in the post post script - "Why do people focus on pages 4, 5, and 6 of a 13-page talk, and forget all about slides 8, 9, 10, 11, 12, and 13, where I make the real point?"
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.
Lots of good reading on plover.com. Back in my Perl days he was one of my favorite writers. He's also the only person who does a clear job of explaining how regular expressions work.
Higher Order Perl is a must read for anyone working in any mainstream dynamic language (Python, Ruby, JavaScript, etc.). There are efforts afoot to port the examples to various other languages, much the way The Little Schemer has been ported and mangled in various ways. It's just a really enlightening book for anyone without a strong functional programming background (and probably even those with a lot of functional programming experience, as it happily bounces back and forth between functional idioms and Perl idioms to produce really interesting code).
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.)
Dude -- this is awful. And I don't like design patterns.
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?)
I agree. His understanding of how you might apply these patterns in C++ seems substandard, at best. Doesn't he know about std::<container_type>::iterator? He didn't even seem to know about templates at all.
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.
Doesn't mean I haven't read about patterns, or pieces of the GoF book (which I have; and I'm reading the book itself right now). That would be like saying you can't credibly talk about graphics unless you've read the white book: it simply isn't so.
What the author says happened to the words "Design Patterns" happened to the words "Object Oriented" in the late 90's. Words were appropriated to mean something other than the original intention. Alan Kay has explicitly stated that by "Object Oriented" he didn't mean something like Java. (Alan Kay once stood up in front of Smalltalk Solutions conference as keynote speaker and castigated the whole Smalltalk community saying: "I didn't mean Smalltalk to be a Programming Language!" * )
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.)
* 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.
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.