4 ms·

>, the good old Design Patterns book, responsible for more atrocious over-abstracted, This is a misunderstanding of the DP book. It would be similar to sayin

by jasode 10y ago

>, the good old Design Patterns book, responsible for more atrocious over-abstracted, This is a misunderstanding of the DP book. It would be similar to saying that the existence of TVTropes.com is responsible for terrible scripts of tv shows and movies. Or, the existence of the Oxford English Dictionary is responsible for bad novels and useless documentation. The DP book is a catalog (to gain awareness) and not a checklist (that you must do). It's a collection of observations about software structures out in the wild. It's not about prescription. Even without the phrase "design patterns", it's easy to surmise that programmers out there are independently and unknowingly re-inventing the same higher-level structures (similar to tv tropes) but without giving them formal names. The DP book gives them formal names and hence, an attempt at shared vocabulary. One can go to the amazon.com page for Design Patterns and click "Look inside" for the "First Pages" and see that the authors wanted to present a catalog: https://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612 https://www.amazon.com/Design-Patterns-Elements-Reusable-Obj...

dragonwriter 10y ago
> >, the good old Design Patterns book, responsible for more atrocious over-abstracted, > This is a misunderstanding of the DP book. It is discussing an effect of the book, not the intent. > It would be similar to saying that the existence of TVTropes.com is responsible for terrible scripts of tv shows and movies. Which would be entirely accurate if script writers were widely using TVTropes pages as templates and creating bad scripts from it, regardless of what TVTropes is intended to be.
- jasode 10y ago
  >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.
  - davik 10y ago
    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.
    - jasode 10y ago
      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-1404417569 https://www.wsj.com/articles/the-summers-most-unread-book-is...
      - dpdawson 10y ago
        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.
        dwaltrip 10y ago
        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.
  - 10y ago
deleted 10y ago
[deleted]
iak8god 10y ago
> This is a misunderstanding of the DP book. That may be, but it's a very common misunderstanding of the book by junior developers who read the book as a list of recipes to use anywhere they might be applicable. Is it the book's fault that it's understood this way? I don't know. Regardless, the book + this persistent understanding and use of it are, as grabcocque says, "responsible for more atrocious over-abstracted, unreadable, hard to maintain Java code than anything else before or since."
- goostavos 10y ago
  I dunno if it's just _junior_ ones. I've encountered my share of "enterprise architects" that will use this book as though it were a bible when trying to justify their near-insane scribbling of boxes and lines on the white board.
  - iak8god 10y ago
    Yes, well, some of the juniors never repent. Plus it's a decent tactic for job security through obscurity...
- dragonwriter 10y ago
  The facts that the book focuses on exactly the kind of patterns which are not abstractable into libraries in the popular OOP languages of the time (mostly true now, too), and that the implementation of each pattern is central to the presentation -- both of which arguably have quite good reasons based on the books intended role, to be sure -- I think promote this misunderstanding. Certain other design patterns books in the software field (Patterns of Enterprise Application Architecture and Enterprise Integration Patterns, for examples that happen to be on the shelf next to me at the moment) don't share those features.
lkozma 10y ago
Still, the original architecture "Design Patterns" book by Alexander (which this book is supposed to be the software analogy of) discusses "good practices", emphatically recommended for architects, city planners, etc. So it is maybe not that far-fetched to interpret these patterns as recommendations too.
ryandrake 10y ago
Unfortunately, it tends to be _read_ as a how-to book rather than as a catalog of observations. I have actually heard from a professional software engineer, "We can't write the code this way because it's not using any known design pattern," said with a straight face. This is partially the mentality that gives us things like the classic AbstractSingletonProxyFactoryBean[1] class. 1: https://news.ycombinator.com/item?id=4549544 https://news.ycombinator.com/item?id=4549544
msluyter 10y ago
I've seen this argument before, but I don't really buy it. Why did they subtitle their book "elements of reusable object oriented software" if they didn't intend to present "patterns" as "templates." (After all, "reusable" is a good thing, right? So if you follow these patterns your code will be reusable, hence, good.) Why did they use the word "pattern" at all? Why not name the book "Software Structures: observations about software out in the wild?" In any event, it doesn't really matter what the original intent of the GoF book is because in practice, people treat design patterns as, well, what the word "pattern" would suggest: "something designed or used as a model for making things <a dressmaker's pattern>". This is further indicated by the term "anti-pattern," which basically means, "something you should avoid." If you should avoid the "anti" then it stands to reason you should follow the "pattern." For even more demonstrations of this fact, look at subsequent design patterns book, like one by the Head First. These explicitly treat patterns as improvements to be made over some previous attempt at a coding problem. Or hell, check out this description from https://sourcemaking.com/design_patterns https://sourcemaking.com/design_patterns -- "Design patterns can speed up the development process by providing tested, proven development paradigms." " Reusing design patterns helps to prevent subtle issues that can cause major problems and improves code readability for coders and architects familiar with the patterns." Whether it was the original intent of the GoF or not, design patterns are mostly perceived to be _good things_ that should be adhered to. Now, as many have suggested, the wisdom of reaching for design patterns has been increasingly viewed with skepticism, and rightly so. It'll be interesting to see over time how much weight they carry and where the equilibrium lies. My guess is that certain patterns will essentially fade from relevance (if your language has first class methods, do you really need Strategy, for example?) While some (adapter, facade) remain useful ways of handling various problems.
bphogan 10y ago
The GoF book is responsible for a lot of bad decisions made by inexperienced devs because colleges insist on using it as a textbook. It's the textbook used in most Java-based CS programs for their Design Patterns courses. It was when I was in school and it still is now. Mainstream developers who attend schools that produce Java developers believe that this is a recipe book. I have seen this book used at conference talks for nearly 20 years. Countless blog posts aimed at beginners reference this book as the way to solve problems. The book itself is pretty explicit that they are not recipes, but that doesn't mean it isn't used that way. Don't blame the book - blame the curriculum that's based on it.
agumonkey 10y ago
A friend used to say that, he likes to share vocabulary, so they can avoid duplication. Which is entirely true, that said this book gave me nightmare, because I found the mindset so ceremonious; borderline off topic. Giving name like flyweight to a simple "compression" scheme... The whole thing felt like "duh" to me. Sure it give common ground to people; but none of it felt like something to be written down, even less worshiped like it was. I also strongly feel about the critics saying that it targets poor OOP languages (cpp, java <5), rendering the whole thing moot in other paradigms.

by jasode 10y ago

dragonwriter 10y ago

> >, the good old Design Patterns book, responsible for more atrocious over-abstracted, > This is a misunderstanding of the DP book. It is discussing an effect of the book, not the intent. > It would be similar to saying that the existence of TVTropes.com is responsible for terrible scripts of tv shows and movies. Which would be entirely accurate if script writers were widely using TVTropes pages as templates and creating bad scripts from it, regardless of what TVTropes is intended to be.

jasode 10y ago
>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.
- davik 10y ago
  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.
  - jasode 10y ago
    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-1404417569 https://www.wsj.com/articles/the-summers-most-unread-book-is...
    - dpdawson 10y ago
      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.
      - dwaltrip 10y ago
        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.
- 10y ago

deleted 10y ago

[deleted]

iak8god 10y ago

> This is a misunderstanding of the DP book. That may be, but it's a very common misunderstanding of the book by junior developers who read the book as a list of recipes to use anywhere they might be applicable. Is it the book's fault that it's understood this way? I don't know. Regardless, the book + this persistent understanding and use of it are, as grabcocque says, "responsible for more atrocious over-abstracted, unreadable, hard to maintain Java code than anything else before or since."

goostavos 10y ago
I dunno if it's just _junior_ ones. I've encountered my share of "enterprise architects" that will use this book as though it were a bible when trying to justify their near-insane scribbling of boxes and lines on the white board.
- iak8god 10y ago
  Yes, well, some of the juniors never repent. Plus it's a decent tactic for job security through obscurity...
dragonwriter 10y ago
The facts that the book focuses on exactly the kind of patterns which are not abstractable into libraries in the popular OOP languages of the time (mostly true now, too), and that the implementation of each pattern is central to the presentation -- both of which arguably have quite good reasons based on the books intended role, to be sure -- I think promote this misunderstanding. Certain other design patterns books in the software field (Patterns of Enterprise Application Architecture and Enterprise Integration Patterns, for examples that happen to be on the shelf next to me at the moment) don't share those features.

lkozma 10y ago

Still, the original architecture "Design Patterns" book by Alexander (which this book is supposed to be the software analogy of) discusses "good practices", emphatically recommended for architects, city planners, etc. So it is maybe not that far-fetched to interpret these patterns as recommendations too.

ryandrake 10y ago

Unfortunately, it tends to be _read_ as a how-to book rather than as a catalog of observations. I have actually heard from a professional software engineer, "We can't write the code this way because it's not using any known design pattern," said with a straight face. This is partially the mentality that gives us things like the classic AbstractSingletonProxyFactoryBean[1] class. 1: https://news.ycombinator.com/item?id=4549544 https://news.ycombinator.com/item?id=4549544

msluyter 10y ago

I've seen this argument before, but I don't really buy it. Why did they subtitle their book "elements of reusable object oriented software" if they didn't intend to present "patterns" as "templates." (After all, "reusable" is a good thing, right? So if you follow these patterns your code will be reusable, hence, good.) Why did they use the word "pattern" at all? Why not name the book "Software Structures: observations about software out in the wild?" In any event, it doesn't really matter what the original intent of the GoF book is because in practice, people treat design patterns as, well, what the word "pattern" would suggest: "something designed or used as a model for making things <a dressmaker's pattern>". This is further indicated by the term "anti-pattern," which basically means, "something you should avoid." If you should avoid the "anti" then it stands to reason you should follow the "pattern." For even more demonstrations of this fact, look at subsequent design patterns book, like one by the Head First. These explicitly treat patterns as improvements to be made over some previous attempt at a coding problem. Or hell, check out this description from https://sourcemaking.com/design_patterns https://sourcemaking.com/design_patterns -- "Design patterns can speed up the development process by providing tested, proven development paradigms." " Reusing design patterns helps to prevent subtle issues that can cause major problems and improves code readability for coders and architects familiar with the patterns." Whether it was the original intent of the GoF or not, design patterns are mostly perceived to be _good things_ that should be adhered to. Now, as many have suggested, the wisdom of reaching for design patterns has been increasingly viewed with skepticism, and rightly so. It'll be interesting to see over time how much weight they carry and where the equilibrium lies. My guess is that certain patterns will essentially fade from relevance (if your language has first class methods, do you really need Strategy, for example?) While some (adapter, facade) remain useful ways of handling various problems.

bphogan 10y ago

The GoF book is responsible for a lot of bad decisions made by inexperienced devs because colleges insist on using it as a textbook. It's the textbook used in most Java-based CS programs for their Design Patterns courses. It was when I was in school and it still is now. Mainstream developers who attend schools that produce Java developers believe that this is a recipe book. I have seen this book used at conference talks for nearly 20 years. Countless blog posts aimed at beginners reference this book as the way to solve problems. The book itself is pretty explicit that they are not recipes, but that doesn't mean it isn't used that way. Don't blame the book - blame the curriculum that's based on it.

agumonkey 10y ago

A friend used to say that, he likes to share vocabulary, so they can avoid duplication. Which is entirely true, that said this book gave me nightmare, because I found the mindset so ceremonious; borderline off topic. Giving name like flyweight to a simple "compression" scheme... The whole thing felt like "duh" to me. Sure it give common ground to people; but none of it felt like something to be written down, even less worshiped like it was. I also strongly feel about the critics saying that it targets poor OOP languages (cpp, java <5), rendering the whole thing moot in other paradigms.