
"Design Patterns" Aren't - initself
http://perl.plover.com/yak/design/
======
gruseom
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.

~~~
michaelneale
>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.

~~~
gruseom
Yeah, good point - that's a much better way to draw the analogy. (For some
reason I missed this comment when the thread was current.)

------
olavk
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.

~~~
njharman
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.

------
tonystubblebine
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.

~~~
SwellJoe
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.)

~~~
astrec
Talk about porting: The Little Schemer was The Little Lisper when I was in
school.

~~~
Hexstream
Well, scheme is a lisp so in a sense "The Little Schemer" is still "The Little
Lisper".

------
stcredzero
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.)

------
KevBurnsJr
_Object Oriented Software Design_ and _Architecture and Planning_ are two very
different activities.

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.

------
gasull
In a nutshell, FTA:

* _People are using 1970s-era languages_

* _The "Design Patterns" solution is to turn the programmer into a fancy macro processor_

~~~
olavk
But the point he actually wanted to convey was:

* 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.

------
DanielBMarkham
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?)

~~~
aggieben
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.

~~~
SwellJoe
_I have yet to read the GoF book_

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.

~~~
aggieben
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.

