5 ms·

The usage of that Paul Graham quote is hilarious. The author misses the point entirely! Graham uses the word pattern to describe a repeated piece of code that m

The usage of that Paul Graham quote is hilarious. The author misses the point entirely! Graham uses the word pattern to describe a repeated piece of code that matches a pattern. And it's a sign of trouble: a violation of the DRY principle. Nothing to do with design patterns really. Are all the other quotes used as unsuitable, we don't know.

TeMPOraL 10y ago
No, the author does not miss the point - though I assume he may not understand it fully. The quote is written in context of Lisp macro facilities, which let you DRY your code from a lot of things, including GoF-style design patterns. So e.g. if you see yourself using "Memento pattern" (or whatever) in many places in your code, writing the same kind of methods doing the same thing everywhere, you should consider writing a macro that'll do that for you instead. That is, if your language lets you do that. Design patterns really start where the language's ability to abstract ends.
- kyberias 10y ago
  No, I don't think so. That's not a critique towards design patterns. It's critique towards ANY CODE THAT IS REPEATED. If I use a certain design pattern once in my code, I didn't repeat anything. Macros don't remove the design pattern, they just allow me not to repeat myself.
  - TeMPOraL 10y ago
    You rarely use design patterns only once in a project. And while this quote does not cover it, you can also use macros to better communicate that one-off design pattern instance - instead of identifying a pattern by noticing a set of familiar methods or a typical inheritance graph, the person reading your code can just see the the macro invocation and know he's dealing with a particular design pattern here. Design patterns aren't bad per se, even if they imply some problems with language's capabilities to abstract - because they shift an abstraction from code to programmers' shared knowledge. The problem is with what I would call "design-pattern-driven development" - attempting to fit your problem into the bunch of design patterns you know. It's unfortunately very common.
    - kyberias 10y ago
      I don't think there's such a problem really. We all try to fit the problems we encounter in designing software into a bunch of knowledge that we know. That bunch might be a set of design patterns. There's nothing wrong with that. Sometimes they fit perfectly and sometimes they don't. Sometimes the software we produce is not perfect.

TeMPOraL 10y ago

No, the author does not miss the point - though I assume he may not understand it fully. The quote is written in context of Lisp macro facilities, which let you DRY your code from a lot of things, including GoF-style design patterns. So e.g. if you see yourself using "Memento pattern" (or whatever) in many places in your code, writing the same kind of methods doing the same thing everywhere, you should consider writing a macro that'll do that for you instead. That is, if your language lets you do that. Design patterns really start where the language's ability to abstract ends.

kyberias 10y ago
No, I don't think so. That's not a critique towards design patterns. It's critique towards ANY CODE THAT IS REPEATED. If I use a certain design pattern once in my code, I didn't repeat anything. Macros don't remove the design pattern, they just allow me not to repeat myself.
- TeMPOraL 10y ago
  You rarely use design patterns only once in a project. And while this quote does not cover it, you can also use macros to better communicate that one-off design pattern instance - instead of identifying a pattern by noticing a set of familiar methods or a typical inheritance graph, the person reading your code can just see the the macro invocation and know he's dealing with a particular design pattern here. Design patterns aren't bad per se, even if they imply some problems with language's capabilities to abstract - because they shift an abstraction from code to programmers' shared knowledge. The problem is with what I would call "design-pattern-driven development" - attempting to fit your problem into the bunch of design patterns you know. It's unfortunately very common.
  - kyberias 10y ago
    I don't think there's such a problem really. We all try to fit the problems we encounter in designing software into a bunch of knowledge that we know. That bunch might be a set of design patterns. There's nothing wrong with that. Sometimes they fit perfectly and sometimes they don't. Sometimes the software we produce is not perfect.