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).<p>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.<p>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.
An interesting part is the addendum in the postscript, where he wonders why "almost everyone who has read this has completely missed the point".<p>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.
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.
Dude -- this is awful. And I don't like design patterns.<p>If you're going to trash something, at least know enough about it to be able to describe what you're trashing.<p>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?)
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 <i>Programming Language</i>!" * )<p>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?<p>( * - He originally meant it to be something like the OLPC operating system.)
In a nutshell, FTA:<p>* <i>People are using 1970s-era languages</i><p>* <i>The "Design Patterns" solution is to turn the programmer into a fancy macro processor</i>
<i>Object Oriented Software Design</i> and <i>Architecture and Planning</i> are two very different activities.<p>It's no wonder that Patterns in each discipline should vary so widely.<p>As different from each other as they are from 1920s <i>Stitching</i> Patterns sold in catalogs with bulk cloth.