I agree with the article except for those 2 paragraphs: "Norvig once wrote that the existence of design patterns is a sign of weakness in a language. I think h

I agree with the article except for those 2 paragraphs: "Norvig once wrote that the existence of design patterns is a sign of weakness in a language. I think he was wrong there. Sure, certain patterns are only necessary because a language don't allow to archive a certain goal directly by some build-in concept. But if you build it in, you would quickly discover other patterns 'a level above' instead of getting rid of those pesky design patterns. So we always have patterns, it's simply unadvoidable." The problem is when you have to "hand-compile" a pattern repeatedly because the language doesn't let you abstract it away. Closures and macros let you codify most of those patterns once and for all. "A concrete example: Java uses the "Iterator pattern" quite frequently. Now in functional programming this pattern is quite useless. We simply write map and fold functions and don't need no "iterator". Hah! But hey, isn't "writing a map and a fold function" not also a design pattern? All we need to do is to call it the "map and fold"-pattern. Using this pattern is common knowledge for every user of functional programming languages - so it's good to teach this pattern novices in functional programming right from the beginning." But I don't have to reimplement map and fold every time I need to use it, I just need to call it. Whereas most of the time what we call a "design pattern" is something you have to reimplement all across the system by hand.