6 ms·

The most misunderstood book in CS

29 points by nreece 18y ago

BrandonM 18y ago
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.
Alex3917 18y ago
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.
- ajross 18y ago
  I'd have to put Brooks' The Mythical Man Month up there as most misunderstood. I've seen that book used to justify all sorts of nonsense.
  - zenspider 18y ago
    Alternatively, I've used that book to _prevent_ all sorts of nonsense. It can be great when you have a manager who is inexperienced with software development (sad, but too common in some places). "No, we shouldn't add an offshore team to meet our deadline, and here's why..."
- aaronblohowiak 18y ago
  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.
  - deleted 18y ago
    [deleted]
gruseom 18y ago
The most overrated book in CS is more like it.
- aaronblohowiak 18y ago
  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 18y ago
    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.)
Darmani 18y ago
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 http://blog.plover.com/prog/design-patterns.html .)
- gruseom 18y ago
  The post you link to is worth reading. I hadn't seen it before, so thanks for obligatorily pulling it out :)
- DougBTX 18y ago
  You can't do "include Singleton" until you've identified the "Singleton" pattern. The author says that identifying high level patterns is a) the point of the book (for OO languages), and b) that identifying patterns is a good thing. The author is perfectly right to say that interpreting a book which catalogues patterns in existing software as a prescription for how to implement new software is a great misunderstanding, as you've demonstrated in the post above.
Hexstream 18y ago
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 18y ago
  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.)
william42 18y ago
Immediately from the title I knew it was going to be about Design Patterns.
lst 18y ago
Superficial, flawed, simplistic.
deleted 18y ago
[deleted]
jlouis 18y ago
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?
altano 18y ago
The most misunderstood book in CS is R.L. Stine's Goosebumps

29 points by nreece 18y ago

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.

Alex3917 18y ago

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.

ajross 18y ago
I'd have to put Brooks' The Mythical Man Month up there as most misunderstood. I've seen that book used to justify all sorts of nonsense.
- zenspider 18y ago
  Alternatively, I've used that book to _prevent_ all sorts of nonsense. It can be great when you have a manager who is inexperienced with software development (sad, but too common in some places). "No, we shouldn't add an offshore team to meet our deadline, and here's why..."
aaronblohowiak 18y ago
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.
- deleted 18y ago
  [deleted]

gruseom 18y ago

The most overrated book in CS is more like it.

aaronblohowiak 18y ago
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 18y ago
  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.)

Darmani 18y ago

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 http://blog.plover.com/prog/design-patterns.html .)

gruseom 18y ago
The post you link to is worth reading. I hadn't seen it before, so thanks for obligatorily pulling it out :)
DougBTX 18y ago
You can't do "include Singleton" until you've identified the "Singleton" pattern. The author says that identifying high level patterns is a) the point of the book (for OO languages), and b) that identifying patterns is a good thing. The author is perfectly right to say that interpreting a book which catalogues patterns in existing software as a prescription for how to implement new software is a great misunderstanding, as you've demonstrated in the post above.

Hexstream 18y ago

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 18y ago
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.)

william42 18y ago

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

lst 18y ago

Superficial, flawed, simplistic.

deleted 18y ago

[deleted]

jlouis 18y ago

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?

altano 18y ago

The most misunderstood book in CS is R.L. Stine's Goosebumps