Hacker News Reader

Comment by tptacek | Hacker News Reader

Don't buy the Gang of Four book.

I disagree. It’s a foundational piece of software engineering literature, even if it is mostly misapplied. If nothing else, it is important to understand the vocabulary presented in GoF.

Don’t buy it if you think its going to teach you how to write software better. Do buy it if you might ever get dropped in a OO software base written in the last ~20 years. Because understanding the context of the names is important.

Arguably it's important the same way The Fountainhead is important: a work based on an outdated and fundamentally wrong idea that a lot of people still think is gospel and would solve everything. Something something know your enemy.

If the OO software base is C++ with UML diagrams from 1997, sure. But even the terms themselves, their contexts of application have drifted quite a bit. The book is by now mostly a historical record of the fascinating Zoroastrian-like effort to give 101 names to two things - 'don't call us, we'll call you' (observer-observable/callback) and 'I'll have my people call your people' (delegation).

I think you can get the vocabulary from online sources now (Norvig's talk alone is a pretty good starting point). I agree about its cultural importance, but if you wrote GoF'y code in 2019, in any language, people would look at you AbstractFactoryFunny.

The Java community made it pretty easy to punch down to them with the over use of the vocabulary. But its still valuable when I tell another developer "that's using a flyweight" for them to not look at me blankly.

And for what its worth I've used GoF patterns in golang in the last 6 months. No one looked at me funny (to my face at least).

Could you give a link to Norvig's talk? I'd be interested to watch it.

I agree. The intended use as a shared vocabulary of precise terms of art never caught on, even though the names are good evocative names that people continue to use when talking about code. I haven't noticed any drop-off in programmers' ability to solve the underlying problems despite design patterns fading from near-compulsory for "any good programmer" to being a historical relic. Likewise, I haven't noticed that programmers communicate any less efficiently today even though it is no longer standard to review the design patterns terminology before every interview.

Applying design patterns to code seemed like a brilliant idea, but for some reason it wasn't a good fit for how people actually work and communicate.

May be, most of the complex code is abstracted in libraries and frameworks these days. So, the design patterns may not be that useful in application code. But back in the days, when I was writing infrastructure code (Server/ORM), design patterns were super important. Without that, I wouldn't have understand any of the code written by my counterpart.

From the horse's mouth :)

I took it from your comment here - https://news.ycombinator.com/item?id=2275899 . Should I remove it from your list?

Why? I thought it was a good book.

Reply on news.ycombinator.com