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 :-).
It heavily depends on what do we call “design pattern.” If something that is considered to be cool by a majority, then I have no opinion on the subject since I am not interested in what the majority thinks at all.
If, OTOH, we are talking about something, that is invented and used inside a team of any size (it might be used by one single developer,) then I am interested in and I am positive these design patterns are indeed a result of re-thinking the experience, but they are always brand new concepts.
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).
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.