There are so many different definitions and opinions around on what design patterns are and all seem to be (more or less) different. Sadly, most ...
For further actions, you may consider blocking this person and/or reporting abuse
This is a powerful idea I hadn't considered. Thanks for sharing!
That is what I tried to summarize in my article :-) (It is not an invention by me, it is a summarization of all the information I got from international design pattern conferences and books on this topic).
I'm not sure I can follow you here, could you please explain this (or redirect me to some resources I can read about it)? I'm not familiar with the connection of these specific programming languages and design patterns.
But these were no design patterns at the time of the development of these languages, were they? I'm only aware of message-passing design patterns, but they claimed to be design patterns only since the book "Enterprise Integration Patterns" and there the concepts of the languages you mentioned have already been applied in different other contexts.
The time is important, of course somebody has to "invent" the solution. But it can only become a design pattern if it has proven to be a solution to a problem in different systems.
So, the "design pattern" is not the original solution one came up with. The design pattern is the description of the solution, not the solution itself. And for a solution description to qualify as a design pattern, it must already exist.
It is the same with the original design patterns from Christopher Alexander. He did not invent the building constructs, it was just a collection of solution descriptions other architects have used in multiple times.
So to sum, of course, behind every design pattern stands a smart mind that initially came up with the solution. But then it was a great idea, not a design pattern yet :-).