7 ms·

I hate to be negative, but as far as I can tell, the only thing this article does is indicate a lack of understanding of design patterns. Equating them to a ps

I hate to be negative, but as far as I can tell, the only thing this article does is indicate a lack of understanding of design patterns. Equating them to a pseudo-intellectual exercise is missing the point by a proverbial mile. Here's a brief explanation: Often when you are coding, you find an interesting solution to a problem. Then when you look at someone else's code, in a different domain, you realise that they are using a very similar solution. You ask them where they got the idea and they say that they saw it in some code in yet a different domain. So you think, "Hey, this seems to be a useful solution to a problem that occurs in several domains". You tuck it away in the back of your mind and when you see that problem again you say, "I've got a solution to that problem!" and you use it. That's a design pattern. Everybody uses them. The alternative is to bloody mindedly refuse to learn and to use completely novel approaches to the same problems every time you see them. That fact that people write down these solutions and give names to them doesn't suddenly make the solutions ridiculous. The fact that some programmers mindlessly apply "patterns" in the hopes that they can escape thinking doesn't make the solutions bad. That's like saying we should never make libraries because some bad programmers think they can glue 1500 libraries together to make a website without having to know how to program. What the author is complaining about has nothing to do with design patterns. People sitting around building mythical designs that never get built has been going on since before the time of Fred Brooks. There are whole classes of architects, analysts, and consultants who have mastered the art of getting paid big money to talk impressively about software without ever writing a single line of code. Quite a lot of them write popular blogs! That's nothing to do with design patterns. I am half curious to read the author's rants about OO, but I suspect I'll find more of the same -- some programmers wrote some terrible, terrible code and called it OO. It must stop! Sigh...

Shorel 9y ago
I'm partial of the explanation of DP as missing language features. In fact, Design patterns all use the human compiler to check for correctness of implementation. PaulGraham said "Peter Norvig found that 16 of the 23 patterns in Design Patterns were 'invisible or simpler' in Lisp." With this mindset, functions (or subroutines) are language patterns in assembler. In the other extreme, if you use a sufficient advanced language, all your language patterns are actually checked by the compiler and/or interpreter, instead of the programmer. They stop being patterns and are just language features. http://wiki.c2.com/?AreDesignPatternsMissingLanguageFeatures http://wiki.c2.com/?AreDesignPatternsMissingLanguageFeatures
- pasabagi 9y ago
  Isn't there a point where it's more desirable to have 'features' available through patterns, than through the language itself? The larger and more complex the language grows, the more cognitive overhead - so programmers of a hypothetical 'perfect' future language might still use patterns, simply so the language didn't grow out of reasonable proportions.
  - sideshowb 9y ago
    If code is data then in principle you could implement them as libraries rather than language extensions. I don't use lisp or haskell enough to know whether someone has already done this. That said I'm also not convinced that it would help in many cases. What would you enforce about a wrapper for example other than it's constructed from one argument and returns a different type containing a reference to the original one? If you're not able to do that yourself then would a wrapper library really be any use?
- larzang 9y ago
  That's basically the role of frameworks. Any web application I build is going to need at least some subset of functionality common to all web applications, and implementing everything from first principles is absurd, so I use a framework. Someone else building something completely different with the same language doesn't need those things, so cooking my needs into the language itself is just going to add overhead or force unwanted design choices on to them, but there's probably a different framework for whatever they're doing too.
- mikekchar 9y ago
  Clearly having a language that makes it easy to implement common solutions to problems is a good thing. I don't think this means we should stop studying those solutions though. To take a notorious example, visitor pattern is just a work around for the lack of multiple dispatch. However, I do not have enough fingers to count the number of times I've had to explain the benefits of multiple dispatch to people. And perversely I can say the same about the number of times I've heard people conflate multiple dispatch with functional programming! The truth is that sometimes I have an extensible group of types with relatively static operations, and sometimes I have a relatively static group of types with extensible operations. The techniques I employ to write generic code in both cases is different. Another great example is the reactor pattern (a la Douglas Schmidt), which many people view as being the cost of using Node, rather than being a very useful technique for controlling real time processing.
itronitron 9y ago
while I agree with you I think it is also common for authors of articles on design patterns to talk up the design pattern as something new, and give it a horribly abstract name like 'dependency injection' instead of something common and specific that people otherwise familiar with the pattern can easily map their experience to. In the case of 'dependency injection' which to the best of my knowledge is just 'passing in data to the constructor' this may have been a new concept for the people that came up with it, or it may have been a rebranding effort.
- ShaneWilton 9y ago
  What's a less abstract name for dependency injection?
  - hamilyon2 9y ago
    Better boilerplate code constructing things.
    - tuukkah 9y ago
      That's not a name and it's not a good name. Naming is hard: you need a succint yet descriptive and specific phrase. "Dependency injection" nicely evokes the issue of your code depending on other code and how you can avoid hardcoding dependencies by injecting a reference to them at start of execution.
  - deleted 9y ago
    [deleted]
  - itronitron 9y ago
    Constructors With Arguments would be my suggestion
    - ShaneWilton 9y ago
      The main point of dependency injection isn't that you're passing collaborators into the constructor though -- that's just an implementation detail. It's about achieving inversion of control, and using a constructor to inject dependencies is just one example of how to do that. There's also setter based DI, and interface based injection, but again, those are just implementation details.

Shorel 9y ago

I'm partial of the explanation of DP as missing language features. In fact, Design patterns all use the human compiler to check for correctness of implementation. PaulGraham said "Peter Norvig found that 16 of the 23 patterns in Design Patterns were 'invisible or simpler' in Lisp." With this mindset, functions (or subroutines) are language patterns in assembler. In the other extreme, if you use a sufficient advanced language, all your language patterns are actually checked by the compiler and/or interpreter, instead of the programmer. They stop being patterns and are just language features. http://wiki.c2.com/?AreDesignPatternsMissingLanguageFeatures http://wiki.c2.com/?AreDesignPatternsMissingLanguageFeatures

pasabagi 9y ago
Isn't there a point where it's more desirable to have 'features' available through patterns, than through the language itself? The larger and more complex the language grows, the more cognitive overhead - so programmers of a hypothetical 'perfect' future language might still use patterns, simply so the language didn't grow out of reasonable proportions.
- sideshowb 9y ago
  If code is data then in principle you could implement them as libraries rather than language extensions. I don't use lisp or haskell enough to know whether someone has already done this. That said I'm also not convinced that it would help in many cases. What would you enforce about a wrapper for example other than it's constructed from one argument and returns a different type containing a reference to the original one? If you're not able to do that yourself then would a wrapper library really be any use?
larzang 9y ago
That's basically the role of frameworks. Any web application I build is going to need at least some subset of functionality common to all web applications, and implementing everything from first principles is absurd, so I use a framework. Someone else building something completely different with the same language doesn't need those things, so cooking my needs into the language itself is just going to add overhead or force unwanted design choices on to them, but there's probably a different framework for whatever they're doing too.
mikekchar 9y ago
Clearly having a language that makes it easy to implement common solutions to problems is a good thing. I don't think this means we should stop studying those solutions though. To take a notorious example, visitor pattern is just a work around for the lack of multiple dispatch. However, I do not have enough fingers to count the number of times I've had to explain the benefits of multiple dispatch to people. And perversely I can say the same about the number of times I've heard people conflate multiple dispatch with functional programming! The truth is that sometimes I have an extensible group of types with relatively static operations, and sometimes I have a relatively static group of types with extensible operations. The techniques I employ to write generic code in both cases is different. Another great example is the reactor pattern (a la Douglas Schmidt), which many people view as being the cost of using Node, rather than being a very useful technique for controlling real time processing.

itronitron 9y ago

while I agree with you I think it is also common for authors of articles on design patterns to talk up the design pattern as something new, and give it a horribly abstract name like 'dependency injection' instead of something common and specific that people otherwise familiar with the pattern can easily map their experience to. In the case of 'dependency injection' which to the best of my knowledge is just 'passing in data to the constructor' this may have been a new concept for the people that came up with it, or it may have been a rebranding effort.

ShaneWilton 9y ago
What's a less abstract name for dependency injection?
- hamilyon2 9y ago
  Better boilerplate code constructing things.
  - tuukkah 9y ago
    That's not a name and it's not a good name. Naming is hard: you need a succint yet descriptive and specific phrase. "Dependency injection" nicely evokes the issue of your code depending on other code and how you can avoid hardcoding dependencies by injecting a reference to them at start of execution.
- deleted 9y ago
  [deleted]
- itronitron 9y ago
  Constructors With Arguments would be my suggestion
  - ShaneWilton 9y ago
    The main point of dependency injection isn't that you're passing collaborators into the constructor though -- that's just an implementation detail. It's about achieving inversion of control, and using a constructor to inject dependencies is just one example of how to do that. There's also setter based DI, and interface based injection, but again, those are just implementation details.