Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm reading Coders at Work and Brendan Eich cites a paper by Norvig, from when he was at Harlequin, "about how design patterns are really just flaws in your programming language."

Can anyone provide the link to this paper?

share|improve this question
up vote 15 down vote accepted

I think the "paper" is actually the Design Patterns in Dynamic Languages presentation, also cited in Wikipedia for this particular claim:

The design patterns may just be a sign of some missing features of a given programming language (Java or C++ for instance). Peter Norvig demonstrates that 16 out of the 23 patterns in the Design Patterns book (which is primarily focused on C++) are simplified or eliminated (via direct language support) in Lisp or Dylan.

In similar manner, Paul Graham describes design patterns as "the human compiler at work" in Revenge of the Nerds:

This practice is not only common, but institutionalized. For example, in the OO world you hear a good deal about "patterns". I wonder if these patterns are not sometimes evidence of case (c), the human compiler, at work. When I see patterns in my programs, I consider it a sign of trouble. The shape of a program should reflect only the problem it needs to solve. Any other regularity in the code is a sign, to me at least, that I'm using abstractions that aren't powerful enough - often that I'm generating by hand the expansions of some macro that I need to write.

Both quotes are the basis of the Are Design Patterns Missing Language Features discussion on Ward's Wiki.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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