4 ms·

I see only positive reviews for this book here, but I went to look it up on amazon and the first review doesn't look particularly good and I'm looking for anyon

I see only positive reviews for this book here, but I went to look it up on amazon and the first review doesn't look particularly good and I'm looking for anyones reason to refute this: "This book does not consider functional programming, or the fact that terrible software in modern times is often the result of layers of incorrect abstraction that are often induced by the overuse of "object oriented" (OO) programming techniques. Instead, it takes OO programming for granted as being a good thing (visible in its preferences for two OO languages, C++ and Java), and then it reasons in that domain, making it totally uninteresting to many potential readers. The book also assumes that formal design doesn't work (he calls it "waterfall"), and takes alternatives for granted. I doubt the author is even aware of his inherent bias, but it is incredibly strong." Does anyone here agree or disagree with these points?

jwdunne 6y ago
Hrm, I read the book and the code samples were in mainstream languages, naturally, but there wasn’t a specific reference to OO. Algorithms by Sedgewick had more reference to OO but we don’t say that book is overly biased towards OO. The text isn’t about implementation or paradigm. It’s about things applicable in software design in general. For example, good interfaces are deep, rather than shallow. The examples of narrow interfaces are in Java because they were good examples. If you have to instantiate 5, 6 objects to use an interface, the interface is not deep. But if you had to do the same thing in a CLI interface or a GUI, it’s the same idea. You could apply the same ideas to functional APIs.
floppy-disk 6y ago
I would not agree that the bias towards OOP is a problem in the book, since most of the concepts are paradigm-agnostic. Nevertheless, I feel that the author exposes a rather opinionated (sometimes even dogmatic) and narrow view of software design. Although I think that the book provides a lot of very valuable insights, I missed a more differentiated view of the concepts presented in the book. For example, in chapter 4 ("Modules should be deep") Ousterhout dismisses the use of small classes and methods. He argues that using many small classes and methods makes the system as a whole more complex because many little pieces have to be managed. I completely agree with that statement. But only under the assumption that software systems are static and never-changing. If we consider software systems as ever-changing, I would argue that using smaller pieces often provides the flexibility necessary for maintaining large systems.
- afarrell 6y ago
  I think that would be better off in a different book rather than as a part of this book. It is better to provide a clear and memorable picture that is only slightly wrong than a hedging and muddled picture that is still slightly wrong.
- derangedHorse 6y ago
  I've also noticed that point in one of his talks and disagreed with it immediately. My own experiences have found small components easier to test and reason about in higher level components. I do think that navigating through a codebase with a lot of small files would make the codebase seem a lot more complex (especially without a modern code editor where you can't do things like click on an interface method and see all its implementations), but the biggest drawback of having small components, in my opinion, is that a lot of the developers I've observed are very bad at drawing coherent software boundaries
  - floppy-disk 6y ago
    > a lot of the developers I've observed are very bad at drawing coherent software boundaries That's a very good point. Designing small components probably requires more effort and can also cause a lot of harm if done incorrectly.
- code_biologist 6y ago
  When arguing against small classes and methods by default, he's in good company: http://number-none.com/blow/john_carmack_on_inlined_code.html http://number-none.com/blow/john_carmack_on_inlined_code.htm... Prior HN discussion: https://news.ycombinator.com/item?id=12120752 https://news.ycombinator.com/item?id=12120752
  - floppy-disk 6y ago
    There are also numerous people which promote the excessive use of small classes and methods like for example Kent Beck or Robert Martin. As always, there probably is no "right" answer, it really depends on context.

jwdunne 6y ago

Hrm, I read the book and the code samples were in mainstream languages, naturally, but there wasn’t a specific reference to OO. Algorithms by Sedgewick had more reference to OO but we don’t say that book is overly biased towards OO. The text isn’t about implementation or paradigm. It’s about things applicable in software design in general. For example, good interfaces are deep, rather than shallow. The examples of narrow interfaces are in Java because they were good examples. If you have to instantiate 5, 6 objects to use an interface, the interface is not deep. But if you had to do the same thing in a CLI interface or a GUI, it’s the same idea. You could apply the same ideas to functional APIs.

floppy-disk 6y ago

I would not agree that the bias towards OOP is a problem in the book, since most of the concepts are paradigm-agnostic. Nevertheless, I feel that the author exposes a rather opinionated (sometimes even dogmatic) and narrow view of software design. Although I think that the book provides a lot of very valuable insights, I missed a more differentiated view of the concepts presented in the book. For example, in chapter 4 ("Modules should be deep") Ousterhout dismisses the use of small classes and methods. He argues that using many small classes and methods makes the system as a whole more complex because many little pieces have to be managed. I completely agree with that statement. But only under the assumption that software systems are static and never-changing. If we consider software systems as ever-changing, I would argue that using smaller pieces often provides the flexibility necessary for maintaining large systems.

afarrell 6y ago
I think that would be better off in a different book rather than as a part of this book. It is better to provide a clear and memorable picture that is only slightly wrong than a hedging and muddled picture that is still slightly wrong.
derangedHorse 6y ago
I've also noticed that point in one of his talks and disagreed with it immediately. My own experiences have found small components easier to test and reason about in higher level components. I do think that navigating through a codebase with a lot of small files would make the codebase seem a lot more complex (especially without a modern code editor where you can't do things like click on an interface method and see all its implementations), but the biggest drawback of having small components, in my opinion, is that a lot of the developers I've observed are very bad at drawing coherent software boundaries
- floppy-disk 6y ago
  > a lot of the developers I've observed are very bad at drawing coherent software boundaries That's a very good point. Designing small components probably requires more effort and can also cause a lot of harm if done incorrectly.
code_biologist 6y ago
When arguing against small classes and methods by default, he's in good company: http://number-none.com/blow/john_carmack_on_inlined_code.html http://number-none.com/blow/john_carmack_on_inlined_code.htm... Prior HN discussion: https://news.ycombinator.com/item?id=12120752 https://news.ycombinator.com/item?id=12120752
- floppy-disk 6y ago
  There are also numerous people which promote the excessive use of small classes and methods like for example Kent Beck or Robert Martin. As always, there probably is no "right" answer, it really depends on context.