
The most misunderstood book in CS - nreece
http://kawagner.blogspot.com/2008/08/most-misunderstood-book-in-cs.html
======
Darmani
The author claims that if a language has features that allow patterns to be
automated, there will still be patterns. Perhaps that's true, but the logic
seems to be that more-than-necessary code-duplication is acceptable because
eliminating 100% of code duplication is impossible -- certainly not a hacker's
worldview. That Ruby needs to explicitly bind a variable to the result of an
expression in an if statement due to lack of ability to implement effective
anaphora does not excuse Java's need to manually implement what in Ruby is
just "include Singleton".

(Whenever a post comes up defending Design Patterns, it's also obligatory that
someone pull out this link: <http://blog.plover.com/prog/design-patterns.html>
.)

~~~
gruseom
The post you link to is worth reading. I hadn't seen it before, so thanks for
obligatorily pulling it out :)

------
Hexstream
I agree with the article except for those 2 paragraphs:

" _Norvig once wrote that the existence of design patterns is a sign of
weakness in a language. I think he was wrong there. Sure, certain patterns are
only necessary because a language don't allow to archive a certain goal
directly by some build-in concept. But if you build it in, you would quickly
discover other patterns 'a level above' instead of getting rid of those pesky
design patterns. So we always have patterns, it's simply unadvoidable._ "

The problem is when you have to "hand-compile" a pattern repeatedly because
the language doesn't let you abstract it away. Closures and macros let you
codify most of those patterns once and for all.

" _A concrete example: Java uses the "Iterator pattern" quite frequently. Now
in functional programming this pattern is quite useless. We simply write map
and fold functions and don't need no "iterator". Hah! But hey, isn't "writing
a map and a fold function" not also a design pattern? All we need to do is to
call it the "map and fold"-pattern. Using this pattern is common knowledge for
every user of functional programming languages - so it's good to teach this
pattern novices in functional programming right from the beginning._ "

But I don't have to reimplement map and fold every time I need to use it, I
just need to call it. Whereas most of the time what we call a "design pattern"
is something you have to reimplement all across the system by hand.

~~~
eru
And if you recognize some applications of your fold look the same over and
over again - you can code this 'meta'-pattern again. If you pretend that fold
was first - then map and filter are good examples. (Though I suspect map and
filter came first and fold was a generalization.)

------
jlouis
It may be the most misunderstood book in CS, but it is definitely one of the
least relevant books in CS as well. Rather than have a programmer
understanding the GOF book, I'd much rather have one who understands the
Dragon book or CLRS for instance. Or a programmer who can code ML, Haskell or
any Lisp fluently.

Here is why: suppose we have a programming knowing Java. We teach him ML. Then
we teach him the design pattern book. He will have one revelation. ML. On the
other hand, suppose we teach him the design pattern book and then teach him
ML. He will have two revelations. "Strategy pattern? Why don't you just pass a
higher order function... oh ... you can't do that easily ... maybe with an
anonymous class .... hmm ... too verbose".

Now, apply that time is the most important commodity. You'll be working as
hard to learn ML with or without the GOF book under your belt. But with ML
under the belt, you'll soar through the GOF-book. Interesting, isn't it?

------
Alex3917
While not exactly CS related, I think the Wisdom of Crowds wins the title for
most misunderstood book hand down. Of the hundreds of times I've seen people
use the phrase in print, I think only two or three have been by people who
actually understood the book.

Just look at the most recent abomination in the NYT article on trolling:

"Technology, apparently, does more than harness the wisdom of the crowd. It
can intensify its hatred as well."

That doesn't even make sense.

~~~
aaronblohowiak
Well, it makes sense if viewed in the light of democracy and mobs. As long as
people remain civil, groups tend to do better than individuals. When that
breaks down and malice gains momentum (forgive me for mixing social sciences
and physics), mayhem ensues.

------
gruseom
The most overrated book in CS is more like it.

~~~
aaronblohowiak
That depends on how much you value having names for high-level programming
patterns, and how long you've been coding before you read it. I think it is
great for junior developers to read so they can get an idea of what to expect,
and how to apply encapsulation and real-world OOP.

This book is more like the urbandictionary.com than Strunk & White, and some
people get that backwards.

~~~
gruseom
_I think it is great for junior developers to read_

I don't think so. In my observation, the primary effect of _Design Patterns_
was to popularize a way of thinking (programming as the stringing-together of
predefined constructs) that led a lot of people to write hyper-patterny bad
code. This stuff, with its layers of tangled pseudo-abstraction, turned out to
be harder to read, work with, and clean up than the plain old bad code they
were writing before. But it felt sophisticated to the ones producing it, and
they thought they were doing things the "right" way. Of course it's not the
authors' fault how others used their book. But as Tim Lister cleverly said
(about something else), "if everybody gets it wrong there must be something
wrong with _it_." And I do think there was something misleading about the
model the book promoted.

For example, the GoF "patterns" are not at all the same kind of thing,
something that the technical format of the book obscured. Some (Decorator) are
so simple and ubiquitous that calling them a pattern is silly (like talking
about a "parameter" pattern). Others (Iterator) are true formalisms which, as
has been pointed out many times, can and should be dealt with at a language
level (for the same reason we don't have a "subroutine" pattern). Others
(Interpreter) are so general that talking about them as patterns, let alone
trying to create a canonical implementation of them, is pointless. Others
(Abstract Factory) sound good at first, but are so different every time that
they can't be effectively reasoned about (and god, did people make a mess with
those). But _Design Patterns_ promoted the idea that this was a collection of
similar mechanisms, like tools in a toolbox, or a collection of standardized
parts that the programmer would recognize the need for and plug in where
appropriate. It sounded good, and came in a pseudo-technical encoding which
was the real genius of the book from a sales point of view. But in my
observation the whole approach broke down rather quickly in practice.

(Edited in a feeble attempt to make shorter.)

~~~
aaronblohowiak
Thanks for your reasoned and thoughtful reply. I've voted you up.

However, I disagree with your central thesis. Programming _is_ the stringing
together of predefined constructs. However, like all matters of taste, the
hard part is _when_ things are appropriate. Reading the rest of your post as
"GoF does not adequately teach when to use redirection, and other techniques
of abstraction, leading to sophistry instead of sophistication," I completely
agree with what you have to say.

The junior programmers that I know who have read GoF DP have been subject to
my endless bashing over the head with the simplicity stick, and so I hope that
they use indirection and abstract techniques only as appropriate.

~~~
gruseom
_I disagree with your central thesis. Programming is the stringing together of
predefined constructs._

I see what you mean. Yes, but in not the sense I meant. My point is that the
predefined constructs in the GoF book are at varying levels of abstraction and
granularity, and mostly can't effectively be strung together in the way the
book implied. That's my attempt to explain why people mostly created messes
when they tried (an empirical observation).

If DP were actually about "indirection and abstract techniques" per se, that
would be fine. But it's more than that. It's a cookbook of specific clumps of
indirection and abstraction. And I don't think programs can be decomposed into
those clumps or composed out of them.

------
william42
Immediately from the title I knew it was going to be about Design Patterns.

------
BrandonM
The writing could use some improvement (it seemed to be written by a non-
native speaker, but if that was the case, the writing was actually not bad),
but I appreciated the ideas the author was addressing and voted it up.

------
altano
The most misunderstood book in CS is R.L. Stine's _Goosebumps_

------
lst
Superficial, flawed, simplistic.

