I saw, here on Programmers, the answer to this question: How does thinking on design patterns and OOP practices change in dynamic and weakly-typed languages? There I found a link to an article with an outspoken title: Are Design Patterns Missing Language Features. But where I found snippets that to me seemed very catchy and that can be probably verified against experience given there is an incentive for that , like:

PaulGraham said "Peter Norvig found that 16 of the 23 patterns in Design Patterns were 'invisible or simpler' in Lisp."

or another sentence that confirms what I recently seen with people trying to simulate classes in JavaScript:

Of course, nobody ever speaks of the "function" pattern, or the "class" pattern, or numerous other things that we take for granted because most languages provide them as built-in features. OTOH, programmers in a purely PrototypeOrientedLanguage? might well find it convenient to simulate classes with prototypes...

I am also taking into consideration that design patterns are a communcation tool. Because even with my limited experience participating in building applications I can see as an anti-pattern(ineffective and/or counterproductive) for example, forcing a small PHP team to learn GoF patterns for small to medium intranet App. I am aware that scale, scope and purpose can determine what is effective and/or productive, but still I didn't managed to find an technical overview about that.

I saw small commercial applications that mixed functional with OOP and still be maintainable, and I don't know if many would need for example in python to write a singleton , but for me a simple module does the same thing.

So are there studies, exhaustive articles or other form of exposition that takes into consideration design patterns vs. workarounds vs. simpler ways to do it, or replacements by language features ?

  • 16
    It would be a mistake to accept anything that Paul Graham says on the subject of programming languages as "objective and factual." Commented Sep 20, 2012 at 20:13
  • 5
    I don't tend to disagree with Paul Graham, but @MasonWheeler is right, evangelists are great for many reasons, but not for their objectivity. Commented Sep 20, 2012 at 20:39
  • 3
    @JimmyHoffa: It's not "evangelists" in general. I take issue with Graham's long history of posting ridiculous material that frequently contradicts himself or his sources and trying to twist the whole thing into appearing consistent. No matter what it is you're advocating for, that's a horrible way to go about it, and it's a bit appalling to me that people actually listen to him. Commented Sep 20, 2012 at 21:52
  • 5
    Would be nice to see some studies, but if you ever used modern functional languages - you already know how obsolete GOF design patterns are, and there is no need for number to prove it more. (Though, they were important in 1990, no doubt).
    – c69
    Commented Sep 21, 2012 at 1:06
  • 3
    @DanielB, every specific paradigm will fail, because the reality is much more complex than any paradigm could ever be. Therefore, each and every problem deserves its own, domain specific model and paradigm.
    – SK-logic
    Commented Sep 21, 2012 at 13:01

1 Answer 1


I'm not aware of any in-depth discussion or study which takes into account all of those things.

That said, the whole argument of "design patterns are just patching missing features in OO languages" is a bit thin, in my opinion. Yes, some design patterns are exactly that, they fill some common gap doesn't even exist in some other language X. These are typically your low-level, simpler design patterns, like some / many of the original ones in the GoF book.

But design patterns go far beyond those simple ones, and calling them missing language features stretches the imagination. Glance over Fowler's catalogue of enterprise application patterns, and think about what it would be like if those were all part of the core definition of a language. I guess you'd end up with domain-specific language (DSL) for enterprise applications (and a very complex one, at that).

So this is the thing, really - design patterns are way to come up with reusable solutions for particular problems (which are often applied in a generic, all-purpose language). This is where communication also comes in. If you tell me "we use Active Records", I already know quite a lot about your application, without spending minutes discussing what the various approaches are. So yes, design patterns do patch holes in the language spec. Is that all that they do? No - not by a long shot.


In a way, what I am saying is that patterns allow OO practitioners to think on a higher level, and almost construct a type of DSL for their environment, while staying within their language's syntax. And yes, I've seen what happens when you apply them everywhere (see: AbstractSingletonProxyFactoryBean, yes, it exists), or think they are some kind of silver bullet. The point is that while they take a long time to get truly comfortable with, they are supposed to actually lower complexity by making things predictable / understandable at a high level. This is very different to being a patch-kit for the failings of your language.

Edit 2 - added the AbstractSingletonProxyFactoryBean counter-example to poke some fun at patterns. To be completely fair, when viewed from an AOP light, even this counter-example is defensible.

  • (+1) and accept because you narrowed my search on DSL and application patterns. Very thoughtful, and can you please expand or link for the reader maybe in parenthesis at least one of the DSL acronyms I suppose it means Domain-Specific Language. Commented Sep 21, 2012 at 11:50
  • @EduardFlorinescu thanks, I've updated with links for DSL.
    – Daniel B
    Commented Sep 21, 2012 at 12:22
  • I also found this article confirming part of your answer in this case with Groovy ibm.com/developerworks/java/library/j-eaed7/index.html Commented Sep 24, 2012 at 11:54
  • 1
    @EduardFlorinescu that's very interesting, although I wasn't just referring to the interpreter pattern specifically; rather, I meant that many patterns can be quite domain-specific, and become almost idiomatic for developers in that domain. In that sense, they become a kind of DSL, and don't take up much effort to understand and use. E.g. when I read through a command pattern (a non-domain specific example), I know which boilerplate code I can safely ignore, and it doesn't take much effort. But thanks for the interesting link, nonetheless.
    – Daniel B
    Commented Sep 24, 2012 at 13:31

Not the answer you're looking for? Browse other questions tagged or ask your own question.