If your point is that design patterns only exist because of insufficiently powerful languages, I disagree. Iterator and Strategy, for instance, are useful conce

If your point is that design patterns only exist because of insufficiently powerful languages, I disagree. Iterator and Strategy, for instance, are useful concepts to be able to talk about in any language, no matter whether they're first-class or not, or how simple the implementation is. If you've got a bunch of lambdas that define alternative ways to accomplish the same end, then why the hell not call them Strategies? I'd also take issue with the implication that Python is powerful enough for the common patterns to disappear completely. it doesn't have macros, for a start, so implementing coupled Strategies of any complexity means you're back in class FooStrategy() land. Recognising when you are or should be implementing a recognised pattern means that you can rely on a lot of analysis of that pattern, largely without paying attention to the environment in which that analysis was performed. That's potentially a big win. I guess what I'm getting at is that throwing away patterns means throwing away a decent lingua franca for talking about the anatomy of your code. Given that, as someone far smarter than me once said, code is primarily for humans to read and only incidentally for computers to execute, that seems like a poor decision.