Comment by jasode | Hacker News Reader

Comment by jasode | Hacker News Reader

Parent Full thread

>It is discussing an effect of the book, not the intent.

Do you truly believe that specific DP book caused that effect?

I don't. The DP book is extremely dry reading and most programmers have not actually read it. ([In terms of readership/ownership ratio] It's a book like Stephen Hawking's "Brief History of Time" ... everybody knows about it and some might have it on the coffee table but very few actually read it.)

I do think the _phrase_ of "design patterns" (not the book) has become a sort of gravitational force such that any discussion about "overcomplicated design" seems to fall toward that particular phrase. Or put differently, "bad designs" is now a synonym of "design patterns" so much so such that you can't even say "design pattern" and have it be interpreted as a neutral term. It's become a trigger word.

>Which would be entirely accurate if script writers were widely using TVTropes pages as templates and creating bad scripts

Yes, I agree that would be equivalent. However, I don't think the existence of tvtropes compels directors like Michael Bay to repeat the "walk away calmly from explosion in the background" scene. The motivation to repeat that "cinematic pattern" comes from somewhere else. Likewise, the majority of bad/overcomplicated abstractions in source code come from somewhere else besides that particular DP book.

I think you are hugely underestimating the influence this book had. This was the first catalog including these patterns and the authors gathered them by looking at source code from many, many projects and compiled common patterns they deemed useful into this book. They named the patterns and this book ultimately popularised them. The book was a huge success when it first came out and I know many people who have indeed read the book. I've even encountered it in university twice. Without this book many of these patterns might not have a name and hardly anybody would know them. They would be patterns in the way that they randomly occur in the wild, but not in the sense that they are templates that developers seek out to solve problems.

> Do you truly believe that specific DP book caused that effect? > > I don't. The DP book is extremely dry reading and most programmers have not actually read it.

This doesn't match my experience but I think that's because you're conflating two related ideas: while few people may have deeply read DP, that's not a requirement for it to have had a strong influence on them, any more than it is necessary for someone to have deeply read and understood their holy book to have strong religious beliefs.

I make that comparison because the worst projects I've seen were heavily based on DP but in a bad way because it was used more as a club than a means for self-improvement. Architects threw it around to bolster their status, a strong push towards ritual cargo culting rather than making sure the problem was well understood enough to know that the code being written matched the actual business case, and any criticism was met with a flak shield of “This is the best practice way according to DP”.

That's not necessarily DPs fault — although there is a discussion to be had about valuing comprehensibility if you want to make meaningful improvements — but it was definitely an effect shaping software development for the worse for over a decade.

Most people have a copy of DP and have not read the whole thing. Most people have read it in that they have read a couple pages, the table of contents, and a couple random patterns. To some extent that is how the book should be read: you have a problem that a DP solves and so you read the section on that pattern to get it right.

The problem is most people have a superficial knowledge of the patterns in the book (a list is easy to put together along with a short summary so most people have read one). They then go looking for how to apply the patterns to their domain so they can check the pattern box, without thinking about the large picture. They never consider that patterns exist to solve a specific problem and if you don't have that problem you shouldn't use the pattern.

The classic example is the singleton: it solves a tricky problem that large systems sometimes have. However few people realize that a singleton is a fancy name for a global variable and have all the downsides of a global variable.

There are several patterns that are a specific way of creating a layer of abstraction. Abstraction layers are often very useful, but as the saying goes: "all problems in programing can be solved by adding a layer of abstraction - except too many layers of abstraction". I've seen cases of layers of abstraction that didn't solve any problems.

As such the original point: DP, by giving patterns names has created more harm than good. This is not the fault of the book though: the names were needed and the patterns are very useful when applied correctly. However before the book people would re-invent the patterns (badly) only when they needed the pattern.

> However few people realize that a singleton is a fancy name for a global variable and have all the downsides of a global variable.

Really? It's been twenty years (maybe a bit more?) since I read the book, but I think this was pretty explicit, was it not?

> Do you truly believe that specific DP book caused that effect

I believe that it, and specific choices made in the selection and presentation of patterns in it, contributed significantly.

> The DP book is extremely dry reading and most programmers have not actually read it.

Perhaps, but the influence of a book (especially one which directly inspires other books) often extends beyond its direct readership.

A very weird comparison, the brief history of time is a popular science book aimed at laymen, it sacrifices precision for a larger audience and is not really a dry book.

Sorry for the confusion. (I've edited my comment for clarity so people don't think I was insulting SH.) I wasn't saying Hawking's prose was dry. That attribute was intended solely for the DP book. With ABHOT, I was comparing the ratio of readers aware of the book vs actually reading it. ABHOT has become sort of a "poster child"[1] among bibliophiles for books owned for vanity and I thought HN readers would get that reference.

[1] example from WSJ that mentions the common meme about ABHOT: https://www.wsj.com/articles/the-summers-most-unread-book-is...

If you own ABHOT and haven't read it, do yourself a favor and give it a shot. It's extremely interesting and a fairly easy read.

Context: My formal physics education ended in high school.

I'll piggyback on you and highly recommend the "crash course astronomy" series on YouTube. It's 50 or so ~10 minute videos that does a broad overview of all of astronomy up to the current moment, starting back when the older civilizations first studied the stars just by looking up with their naked eyes.

It is fast paced and packs a lot of information into each episode, so I do end up rewinding sometimes. And being a passive video, I think retention won't be as high. However, the short videos are very approachable and bite sized. It's very well done and the host is quite entertaining. The past year, my interest in space and physics has increased a bunch. It feels like learning the deeper history and context in which all of humanity is embedded.

I'm actually with the others on this. I've been looking at CompSci papers, engineering methodologies, and real world code going back a long time. I saw a few patterns in use like Parnas' information hiding or state machines. I didn't see GoF patterns until I saw Java people using them while recommending the book. Also, many people in industry forgot about prior methodologies that got results without over-abstraction such as Cleanroom but were all over GoF patterns and latter Agile methodology. It seems their work was pretty influential.

do you know where I could find those other patterns?

You probably have already seen them. It was just things such as structured programming, decomposition into functions, layering with minimal loops between layers, interface checks for invariants, avoiding risky languages/constructs, and usage-based testing.

> Do you truly believe that specific DP book caused that effect?

GoF/Design Patterns was published in 1994. Java, the standard-bearer of overapplying Design Patterns, was first released in 1995, and it only grew into the AbstractAdapterFactoryImpl cliches after that. Based on that timeline Im not really sure how you can argue that GoF had nothing to do with DP madness, at least as exemplified by Java.

Just because GoF was originally meant to be descriptive does not mean that it can't be interpreted as prescriptive, especially by your stock work-a-day software engineer or peter-principle'd software architect. Despite whatever intentions the GoF may have had, by giving these patterns a name, they in a sense codified them, giving people something to point to when justifying otherwise poorly thought out design decisions.

> The DP book is extremely dry reading and most programmers have not actually read it.

The thing about GoF is that you don't really have to read it to apply it--and not actually reading it only increases the odds of mis-applying patterns if youve encountered them elsewhere.

> Do you truly believe that specific DP book caused that effect?

Yes, definitely. People used to cite the GOF book left and right while over-engineering crappy CRUD apps.

Reply on news.ycombinator.com