5 ms·

Disappointingly, the article misrepresents the most serious criticism of the GoF patterns: > we often heard folks say that software patterns existed only becau

by klmr 8y ago

Disappointingly, the article misrepresents the most serious criticism of the GoF patterns: > we often heard folks say that software patterns existed only because people used horrible languages like C++ and Java Maybe folks say that. But (at least when they thought about it a bit more) what they actually mean is that the patterns from the GoF, and similar constructs, only exist because people use “horrible” languages. Nobody is seriously disputing the existence and usefulness of functional design patterns. But they are on a higher level, and arguably more useful, than the basic building blocks from the GoF book. Peter Norvig famously found that most GoF patterns are implicit and not worth talking about in dynamic, functional languages [1]. But he isn’t saying that higher-level patterns are useless or only exist in “horrible” languages. Contrary to what the article says, the common criticism of GoF patterns isn’t an “error”, it’s spot-on. It just criticises something different from what the author thinks: few people seriously criticise the usefulness of Alexander’s pattern language. [1] http://www.norvig.com/design-patterns/ http://www.norvig.com/design-patterns/

fapjacks 8y ago
It is sort of generally true that I usually find myself only using patterns to "fill in" functionality that isn't as easily achievable (or lacking completely) in a particular language. But being able to do this is incredibly important, and I can think of at least one time in my life when having this capability put myself and my team at a significant tactical advantage. I think you could find a lot of parallels with for example AvE on Youtube, who builds the tools he needs when he doesn't have them available. I never heard any of the hype surrounding patterns, so I can't really say whether or not they lived up to it. But I recommend to young programmers that I mentor to learn about patterns, and it's been my experience that they are universally better programmers for it, even if they aren't using them except in edge cases.
Shorel 8y ago
Design patterns without language support are all instances of the human compiler. Some human has to do all the work. In a language with no functions or objects, like assembler, functions and objects are design patterns. You use the subroutine pattern and the abstract data type pattern. Yes, I was taught about abstract data types in C, instead of using a language with objects. This doesn't mean you should forget what functions and objects are if you use a language that supports them. What it means is that the compiler will perform additional checks to ensure the function is well defined, and it will perform additional checks to that objects are well defined. So, a more complex design pattern is something you have to care about and check for yourself in a simpler language, and something you have to care about but also something the language cares about and checks for you, in a more complex language.
- pohl 8y ago
  I like the way you expressed this. It takes longer to say, but is less contentious than Norvig’s pithy quote “Design patterns are bug reports against your programming language.”
specialist 8y ago
Good grief. GoF was wildly successful. Design Patterns was of a time. We were just learning how to talk about design, the design of design. Now that methodologies, heuristics, frameworks, architecture and so forth have become "democratic", it's hard to appreciate the original efforts out of context. Concretely: To Norvig's point, GoF style Design Patterns are just a rung in the programming language maturity ladder. Something like: patterns > idioms > libraries > syntax. Cynically: Design pattern implementations just add another layer of indirection. On the notion that you can, may, or should defer an architectural decision. (Opinions differ. I lean towards YAGNI.) Metaphysically: Mastery is like becoming a jazz musician. First you have to learn the rules before you know how to break them. -- I started a design pattern study group in the 90s, still going strong today. It always kinda goes like this: First reading, mind blown. Second reading, aha, now I see how this could be useful. Third reading, meh, it's obvious, why we still talking about this? Happily, progress marches forward, and there's always something new (or new again) to argue about. Rinse, lather, repeat. -- The sole legitimate criticism is the exploitation of the design pattern zeitgeist. Here's a relevant documentary on that phenomenon. "Exit Through the Gift Shop" https://www.imdb.com/title/tt1587707 https://www.imdb.com/title/tt1587707 Weaponization, misuse, misappropriation of an idea happens every where. I worked for a guy who called everything a Decorator. One of the architects for the Kuali Foundation student project. Took me way too long to figure out he didn't know what a Decorator was. Those conversations were so confusing.
- stcredzero 8y ago
  Took me way too long to figure out he didn't know what a Decorator was. Those conversations were so confusing. Some of the GoF folks used to say most design patterns were just State or Strategy in disguise.
  - specialist 8y ago
    Ya. Just another layer of indirection. In most cases, it's about intent. The "architect" in this story conflated Chain of Command with Decorator. Fire brigade vs call thru. And how that impacts exception handling.
thom 8y ago
It's important to note the difference between the technical mechanism and the motivation for a design. Yes, lots of languages can pass functions around so perhaps you think the Strategy pattern doesn't apply to you. And yet I see huge numbers of APIs that still take enormous option maps and don't offer configuration with some sort of callback, however simple the host language might make it. Patterns capture a design _choice_ as much as a technical implementation.
nabla9 8y ago
GoF style software patterns and the software pattern movement are misunderstanding of Alexander's work and his pattern language. Software patterns are recipe collections. They may be useful as recipe collection and bag of tricks. but that's what they are. Only exception is, of course, Richard Gabriel who studied Alexander's work and read his other books. Christopher Alexander's foreword and the first part of the book Patterns of Software are good intro to Alexander's thinking and how it may inspire software. https://www.dreamsongs.com/Files/PatternsOfSoftware.pdf https://www.dreamsongs.com/Files/PatternsOfSoftware.pdf ps. Richard Gabriel is the author of Worse is Better: https://www.dreamsongs.com/WorseIsBetter.html https://www.dreamsongs.com/WorseIsBetter.html
dbt00 8y ago
I don’t know if you watched the video this blog post is responding to, but I really would because I think it’s a far more important contribution to this conversation than the response. His fundamental point was that design patterns should be about describing knowledge of how different constructs react to each other in combination, and that design patterns as written were mostly about how to build these individual constructs out of just inheritance and methods. Hence the ultimate failure to create a lasting conversation.

by klmr 8y ago

fapjacks 8y ago

It is sort of generally true that I usually find myself only using patterns to "fill in" functionality that isn't as easily achievable (or lacking completely) in a particular language. But being able to do this is incredibly important, and I can think of at least one time in my life when having this capability put myself and my team at a significant tactical advantage. I think you could find a lot of parallels with for example AvE on Youtube, who builds the tools he needs when he doesn't have them available. I never heard any of the hype surrounding patterns, so I can't really say whether or not they lived up to it. But I recommend to young programmers that I mentor to learn about patterns, and it's been my experience that they are universally better programmers for it, even if they aren't using them except in edge cases.

Shorel 8y ago

Design patterns without language support are all instances of the human compiler. Some human has to do all the work. In a language with no functions or objects, like assembler, functions and objects are design patterns. You use the subroutine pattern and the abstract data type pattern. Yes, I was taught about abstract data types in C, instead of using a language with objects. This doesn't mean you should forget what functions and objects are if you use a language that supports them. What it means is that the compiler will perform additional checks to ensure the function is well defined, and it will perform additional checks to that objects are well defined. So, a more complex design pattern is something you have to care about and check for yourself in a simpler language, and something you have to care about but also something the language cares about and checks for you, in a more complex language.

pohl 8y ago
I like the way you expressed this. It takes longer to say, but is less contentious than Norvig’s pithy quote “Design patterns are bug reports against your programming language.”

specialist 8y ago

Good grief. GoF was wildly successful. Design Patterns was of a time. We were just learning how to talk about design, the design of design. Now that methodologies, heuristics, frameworks, architecture and so forth have become "democratic", it's hard to appreciate the original efforts out of context. Concretely: To Norvig's point, GoF style Design Patterns are just a rung in the programming language maturity ladder. Something like: patterns > idioms > libraries > syntax. Cynically: Design pattern implementations just add another layer of indirection. On the notion that you can, may, or should defer an architectural decision. (Opinions differ. I lean towards YAGNI.) Metaphysically: Mastery is like becoming a jazz musician. First you have to learn the rules before you know how to break them. -- I started a design pattern study group in the 90s, still going strong today. It always kinda goes like this: First reading, mind blown. Second reading, aha, now I see how this could be useful. Third reading, meh, it's obvious, why we still talking about this? Happily, progress marches forward, and there's always something new (or new again) to argue about. Rinse, lather, repeat. -- The sole legitimate criticism is the exploitation of the design pattern zeitgeist. Here's a relevant documentary on that phenomenon. "Exit Through the Gift Shop" https://www.imdb.com/title/tt1587707 https://www.imdb.com/title/tt1587707 Weaponization, misuse, misappropriation of an idea happens every where. I worked for a guy who called everything a Decorator. One of the architects for the Kuali Foundation student project. Took me way too long to figure out he didn't know what a Decorator was. Those conversations were so confusing.

stcredzero 8y ago
Took me way too long to figure out he didn't know what a Decorator was. Those conversations were so confusing. Some of the GoF folks used to say most design patterns were just State or Strategy in disguise.
- specialist 8y ago
  Ya. Just another layer of indirection. In most cases, it's about intent. The "architect" in this story conflated Chain of Command with Decorator. Fire brigade vs call thru. And how that impacts exception handling.

thom 8y ago

It's important to note the difference between the technical mechanism and the motivation for a design. Yes, lots of languages can pass functions around so perhaps you think the Strategy pattern doesn't apply to you. And yet I see huge numbers of APIs that still take enormous option maps and don't offer configuration with some sort of callback, however simple the host language might make it. Patterns capture a design _choice_ as much as a technical implementation.

nabla9 8y ago

GoF style software patterns and the software pattern movement are misunderstanding of Alexander's work and his pattern language. Software patterns are recipe collections. They may be useful as recipe collection and bag of tricks. but that's what they are. Only exception is, of course, Richard Gabriel who studied Alexander's work and read his other books. Christopher Alexander's foreword and the first part of the book Patterns of Software are good intro to Alexander's thinking and how it may inspire software. https://www.dreamsongs.com/Files/PatternsOfSoftware.pdf https://www.dreamsongs.com/Files/PatternsOfSoftware.pdf ps. Richard Gabriel is the author of Worse is Better: https://www.dreamsongs.com/WorseIsBetter.html https://www.dreamsongs.com/WorseIsBetter.html

dbt00 8y ago

I don’t know if you watched the video this blog post is responding to, but I really would because I think it’s a far more important contribution to this conversation than the response. His fundamental point was that design patterns should be about describing knowledge of how different constructs react to each other in combination, and that design patterns as written were mostly about how to build these individual constructs out of just inheritance and methods. Hence the ultimate failure to create a lasting conversation.