Are design patterns really language weaknesses?

Question

Some canonized design patterns -- Adapter, Factory, Command, Visitor, etc -- are approximations of features which are baked into other languages. Off the top of my head:

• Event-handlers in C# are baked-in versions of the observer pattern. Think about how you'd wire up events in C# if you had to roll your own observer each time.

• Visitor pattern is a verbose approximation of multimethods, message forwarding, or a really weak form of pattern matching.

• Command pattern wraps up a particular behavior so you can pass the object between methods, which more or less approximates first-class functions.

• Strategy pattern allows you to dynamically insert a behavior into an object, so that at any time you can modify the object by swapping out one behavior with another. In the functional programming world, we call this function composition.

• Abstract factory pattern accepts an argument and returns a factory as a result. In general, you can think of factories as basically wrappers around a function (more specifically, wrappers around a constructor). So, you pass arguments to a function and get a function as a result, making this pattern pretty analogous to currying.

• Decorator pattern allows you to attach or remove behaviors to an object at runtime. In JavaScript, you can add or remove functions without explicitly implementing the decorator pattern thanks to the "prototype" OO model.

So, we have a bunch of design patterns which emulate features intrinsic to other languages. Feature envy doesn't necessarily indicate a weakness in the language -- it's the boilerplate code that you need to write over and over and over which indicates the language weakness.

I wouldn't call them defects.

Higher order languages deal with concepts at a higher level than lower order languages. Think of it in construction terms.

You could build a building at the refinery level, milling lumber, smelting steel, and put together a building that way.

You could purchase boards and steel girders, and construct them into a building.

You could purchase pre-fabricated walls and trusses and construct them into a building.

You could purchase a building and just start with the interior.

Is constructing a building with boards and girders missing the prefabricated wall feature, or defective in some way?

Every single thing that you do three or more times in software designs forms a pattern.

Every repetition. Every repetition. Every repetition.

Some get canonized with cool names. These become Design Patterns. Conscious repetition.

Some are just "best practices" or "this has worked for me." These are design patterns without the clarity.

Some are just "things you usually do." These are design patterns without any conscious recognition that you're repeating yourself.

Design patterns have nothing to do with language weakness or incompleteness. They have everything to do with good ideas, consciously reused.

Today's design patterns are not the royal road to tomorrow's languages. The language paradigm does not advance through a series of "bug fixes to previous languages". If it did, we'd never have created Visual Basic.

And design patterns are a far larger and broader intellectual tool than a simplistic programming language feature set.

No, they are not missing features or defects of the languages. But the languages should provide a means for writing the code for a useful pattern easier rather than difficult. That's where the features that are provided by the language can either be a boon or a hindrance.