
Design patterns aren't - henning
http://perl.plover.com/yak/design/
======
slavak
In his postscript the author explains that he wasn't trying to criticize
design patterns, but was rather trying to promote this other concept; which,
supposedly, is little known in CS circles because of the similar names...

His summary: "We need to take a fresh look at Christopher Alexander."

That's all well and good, and as far as I know the concept of pattern
languages could be very useful; I wouldn't know, I've never heard of it till
today, and in fact still have no idea what it's about. Which brings me to my
point, which is to wonder why the author chose to waste an entire 5 minute and
13 slide presentation (5 of which were dedicated just to bashing design
patterns) to making the point that "we need to take a fresh look at
Christopher Alexander," instead of, say, spending more time introducing
Alexander's ideas and presenting ways they could be useful in our domain.

I will conclude by pointing out another pet peeve of mine, which is
sensationalist titles only tangentially related to the content. Design
pattern, most certainly, ARE. What they are NOT is pattern languages, which is
a similar sounding but entirely different concept.

</ grumpy geezer mode>

~~~
DanielRibeiro
There was also a great discussion about this on Stack overflow:
[http://stackoverflow.com/questions/327955/does-functional-
pr...](http://stackoverflow.com/questions/327955/does-functional-programming-
replace-gof-design-patterns)

TL;DR: Gof had in mind C++ and Smalltalk. Some languages eliminate the need
for many of the patterns in GoF, and they don't eliminate the idioms (patterns
for a particular language), as they barely cover it.

Another good info on the subject is this presentation:
[http://www.infoq.com/presentations/Functional-Design-
Pattern...](http://www.infoq.com/presentations/Functional-Design-Patterns)

------
zzzeek
I'd recommend going over the postscript
<http://perl.plover.com/yak/design/samples/note.html> and note that all the
discussion here has already happened years ago. IMHO if the majority of
listeners misunderstand your talk and don't get the point you're trying to
make, then you made a bad talk. Seems like his real point was to distinguish
between the GOF book and the Alexander book were about. That's great. Present
that point in a thoughtful and careful way, not by going off on GOF in a way
that will turn off listeners/readers and occlude the more subtle point you're
trying to make.

~~~
jerf
"IMHO if the majority of listeners misunderstand your talk and don't get the
point you're trying to make, then you made a bad talk."

Does not follow. It is also possible that he has made a _hard point_ , which
the brains of the readers have a hard time representing with their internal
conceptualizations, therefore misunderstand, then act on those
misunderstandings. I think the presentation is perfectly clear, and do not see
any obvious way it can be made wildly easier to understand.

Quality of communication is not just bounded by the quality of the sender, it
is bounded by the quality of the recipient as well. The point this
presentation is trying to make is intrinsically hobbled by the fact that many
people cognitively will only perceive something that boils down to "PATTERNS
GOOD" (hooray!) or "PATTERNS BAD" (boo! flames!), and "PATTERNS DOGMA A LOSSY
TRANSLATION OF SUPERIOR ORIGINAL PATTERNS CONCEPT" doesn't into either of
those buckets very well (the distinction between patterns dogma and patterns
idea being a tricky one all by itself), and if that's how one approaches it,
it's easy to see how it simply falls into the "bad" bucket.

------
zwieback
When I read the GoF book in '95 it was a revelation, I had learned C++ a few
years earlier and here were all the things I had seen in my and other people's
code with names and explanations. At the time Rogue Wave hosted an informal
lunch meeting in our town where they and some OSU guys discussed patterns, I
attended as a visitor and to me it just seemed magical. Over the years some of
the high hopes have been dashed but I think some of the core pattern ideas
have become useful standard idioms.

A year or so after reading the GoF book I saw the Alexander book in a used
book store and picked it up to see what it was all about and I was very
surprised. I like the book a lot but I really don't think the parallels with
the GoF book and the software design patterns are all that strong. The
Alexander book does not seem very systematic or analytic, it's more rambling
and philosophical. I'm not an architect so I probably don't see the big
picture but to me the book seems to lack a coherent vision.

If you're interested how Alexander himself saw himself fit into the emerging
pattern movement, here's a link to James Coplien's description of Alexander's
OOPSLA appearance in '96:
[https://sites.google.com/a/gertrudandcope.com/info/Publicati...](https://sites.google.com/a/gertrudandcope.com/info/Publications/Oopsla96/feetofmaster-
html)

Hard to believe it's been 15 years!

------
eropple
_paraphrased: "In C++/Java, you write an iterator again and again for every
collection"_

No, you don't. If you write them yourselves (which is in most but all cases
the wrong approach, what with the Java libraries and the C++ STL), you use
templates or generics, as appropriate, to define reusable ones.

In many cases, proper patterns are reusable--and in many cases for good
programmers, design patterns occur automatically just because they're a
logical way to do something. I don't set out to create flyweight objects,
they're the simplest way to achieve my goal. I don't write a thread pool just
to create a thread pool, I write a thread pool because it _makes sense_.

Even in 2002, this was the case. I don't get the feeling that the author of
these slides knew either well enough to make the claims he made.

.

 _The Gang-of-Four idea is to discover existing patterns of software
development / Then program people to implement them habitually_

Er...no. The book _Design Patterns_ is descriptive, not prescriptive. Is that
so hard to get?

.

I am by no means a C++ fan, or even really a GoF fan, but this post is
slagging it just to slag it. If you want to slag it after you understand it,
by all means (and I have perturbed a great many electrons in doing so,
myself), but it doesn't sound like the author does, at all.

~~~
jerf
Few sensible C++ developers in 2002, let alone earlier, could or did use STL
iterators, generics, or templates on a large scale. Yes, they all technically
existed, but it wasn't something you'd put in production code yet. The ideas
and prototypes were a few years old at that point, but the shipping libraries
were very new, and if you were trying to write cross-platform you couldn't
count on them existing at all.

~~~
kenjackson
Maybe my team wasn't sensible, but the main reason we were using C++ in 2002
was for the reasons you described. We admittedly weren't cross platform, but
we found the features compelling -- and while maybe not as stable as we'd like
-- still more stable than most JVMs that were all the rage.

~~~
eropple
Same here. I was writing C++ with templates and the STL in 2002.

Of course, I was also 14 years old and working alone on toy projects, so I
didn't have to worry so much about any of that. ;-)

------
walexander
I think the criticism here on GoF is misdirected.

As far as I'm concerned, GoF is (or at least should be treated as) a taxonomy,
not a cookbook.

The fact that people use it as a cookbook is not necessarily the fault of the
authors.

~~~
ap22213
The GoF value isn't in being a taxonomy. It's about noticing that given
certain environmental conditions and a goal, people will derive similar
solutions. Patterns are just time-savers. So, if you see X, then do Y, because
it will just work.

That's pretty much what Alexander's books say.

The failure of GoF, in particular, is that people took it as a golden rule for
every environment. IIRC, the examined source code was all object oriented c++
and smalltalk code. Yeah - it's not surprising that those patterns aren't
going to work well in, say, Haskell.

~~~
teyc
| _The failure of GoF, in particular, is that people took it as a golden rule
for every environment_

+1

Back in the days of C when assembly was still important, calling conventions
represented patterns that ensure the stack got cleaned up properly. We may no
longer talk about it, it is still there, doing its work silently. The design
patterns were harvested from a language that didn't support lisp-style macros
or continuations or closures.

Patterns are helpful for people who have to work with particular languages,
but are not particularly useful to language designers. But then, they
[language designers] already know that.

------
r00fus
DSL FTW?

The article/presentation seems to imply the benefit of domain-specific
languages for capturing the software requirements (which is what Alexander's
"Pattern Languages" sounds like to me).

How to properly create and re-use DSLs sounds very much like an artform to
me...

~~~
yxhuvud
I thought of that as well, but the reach of the idea goes a long way past
DSLs. It definitely applies to programming language construction in general
and to almost anything you can do with computers.

Find the right abstractions that gives you the right amount of details while
at the same time give you the tools to scale your reasoning about a problem,
and you can move mountains. Find the wrong balance, and you will end up with a
cluttery hell that is impossible to maintain or a blunt tool that doesn't do
anything well.

------
aaimnr
The critique of GoF presented is superficial. The main difference being GoF's
'how' against Alexander's 'what' doesn't come from GoF's misunderstanding of
Alexander's original work. It comes from a different role of architecture of a
building versus an architecture of a computer program. It's easier to say
about Alexander's pattern that it provides an answer for a 'what' question
because the building's architecture is something that people interact with
directly with all their senses. Hence a pattern like "159. LIGHT ON TWO SIDES
OF EVERY ROOM" (
[http://www.patternlanguage.com/apl/aplsample/apl159/apl159.h...](http://www.patternlanguage.com/apl/aplsample/apl159/apl159.htm)
) seems like an end in itself when compared to eg. a iterator pattern, which
obviously always will be described merely as a mean to some more general
functionality of the application.

The truth is, "LIGHT ON TWO SIDES OF EVERY ROOM" is also a mean - a mean to
making a room more bright, pleasant and friendly . If it feels more
substantial than an iterator pattern, it's just because we directly interact
with an architecture of a building in contrast to the architecture of a
software, which is always hidden.

There's nothing wrong with GoF, it just follows from the essential quality of
a computer software.

------
keithnoizu
What, is this not how we've been using design patterns all along? I always
used these patterns to simplify the explanation of how the architecture should
or could work. I've never referred to some master cheat sheet of patterns I
can copy and paste into my source code to save time, you generally need to
custom fit your solutions to the problem at hand.

------
ericbb
Sounds like the Ubiquitous Language idea from Domain Driven Design is a closer
analogue. I haven't read Christopher Alexander's book so I'm just going on the
article's summary.

<http://domaindrivendesign.org/node/132>

