3 ms·
What is the difference between a design pattern and a language idiom? From common usage, a "design pattern" seems to be a way of organizing part of a program t
by silentbicycle 18y ago
What is the difference between a design pattern and a language idiom?
From common usage, a "design pattern" seems to be a way of organizing part of a program that cannot be directly expressed once in the language and then pushed into a library, but instead needs to be mostly rewritten whenever used. (Polyglot programmers usually recognize this as a kind of language weakness. (See: http://weblog.raganwald.com/2006/01/finding-signal-to-noise-ratio-in-never.html http://weblog.raganwald.com/2006/01/finding-signal-to-noise-...) ) If one could just say,
require "visitor.lib";
and move on, then would people make such a big deal about them?
Along similar lines, FP has currying, pattern matching / destructuring-bind, higher-order functions, and monads, among other things. The only one of these I've heard referred to as a design pattern is the monad. Most FP languages just let you do all of the others, but monads require rewriting some (relatively small) infrastructure code. In Haskell, the compiler (via typeclasses) recognizes that you are writing an instance of a known general concept, though, so you don't need to duplicate most of the infrastructure.
If this isn't the case, then why aren't general OO design concepts such as e.g. delegation or inheritance considered design patterns?
- jd 18y ago> What is the difference between a design pattern and a language idiom? A design pattern is simply a name given to the obvious solution given to a common problem. By giving it a name it becomes much easier to talk about / understand the code. Once you know that a class is a proxy class, you don't really care what the methods do anymore, you just dive in and see to which classes the real work is delegated. So one word "proxy" tells you exactly what 400 lines of boilerplate does. A language idiom is different. The purpose of language idioms is to clearly and succinctly express common concepts. The language designers think of a "best" solution, and give it a name. So, really, when you have a bunch of people writing the same code to solve the same class of problem, you give that code a name and call it a design pattern. Patterns emerge AFTER the language is used. Language idioms try to capture the essence of the problem, such that no patterns are necessary. At least, that's how I look at it.