Design pattern as (missing) language feature

Sometimes people refer to design patterns as missing programming language features. To avoid the debate about what is a design pattern, let's say we only consider the original GoF patterns. For instance, the singleton pattern vanishes in Scala which supports singleton objects using the keyword object.

There are few resources around about this, notably Are Design Patterns Missing Language Features from the C2 wiki, or Are design patterns really language weaknesses? from SO. But I couldn't find an non-opinionated, objective and comprehensive coverage of this question.

Ideally, I would like a matrix with the GoF design patterns (row) and some mainstream programming languages (columns), where each cell would refer to a discussion about the pattern in the specific programming language.

To avoid the debate about what PL to consider, we can also fix thi开发者_如何学Gos and pick: Java (as an statically typed OO representative), Smalltalk (as a dynamically typed representative), Haskell (as a functional representative), Scala (as a hybrid oo/functional representative), Lisp (as a meta-programming representative), JavaScript (as a prototype-based representative). And leave other PL for side notes or comments. I know we can argue about this choice, but that would already but really interesting to have that for these languages.

This will anyway always be an open question, but I feel like asked as it is, this is focused enough to have one best answer.

Maybe this matrix already exists somewhere? Or somebody has enough knowledge to craft it? Or somebody is keen enough to start and make it a wiki answer so that other can continue?

The patterns in Design Patterns are a subset of the ever-growing set of patterns people use when programming in different languages. The authors are very clear that those patterns only apply to OOP languages, so many of them won't make sense outside of that context.

At the same time, there are plenty of patterns in other languages that aren't needed in an OOP language. Consider that objects themselves are a pattern when implemented in C or Scheme. In assembly, a call stack is a pattern.

I personally, after spending some years of doing OOP have found that the problem with design patterns, is that they do highlight the problems with OOP and how hard it is to see patterns in data that is so related to the domain in which it is being modelled. It is very hard sometimes to see the wood for the trees. Some artefacts in OOP simply are there to cure the problems that exist when thinking in that particular paradigm or getting around the encapsulated state and access.

I think that design patterns are great and I use them, however they have been regarded as the fix to a problem that may exist in the inability of OOP to be objective about data structures and functions, so that tried and tested formula can be applied. A simple example would be the Singleton Object. This just disappears when using functional languages and is not an issue.

As one gentleman on SO said when I asked about about UML and if it could be used to model Functional Languages, he said that the modelling language of functional programming languages is maths. I think that this is the key to understanding why patterns are not relevant to functional programming languages, as the theory behind them is steeped in the structures of mathematics.

I can't help you with a crib sheet, but I can be pretty certain that the GOF patterns do not apply to functional programming languages, as they go straight to the real patterns of mathematics as the beauty of functional languages is that they map directly (in most cases) to many many years of solving problems in mathematics. Maybe a brash statement is that the design patterns of functional languages are mathematical theorems with a one to one relationship where OO has a form of artificial abstractions that sometimes gets in the way.

I think that there are some design principals that cross against all languages such as MVC, multi-tiered architecture, scaling out and scaling up. But these I would regard as not being design patterns, more of good software design practices.