I loved the GoF book back in the days. I recall it as very well written and very much directed at solving practical problems. Those properties alone set it apart from most books that I encountered during my time at the university.
Being new to Java at that time, the GoF patterns were also a very useful crutch to me when trying to learn to "walk" in the bright and futuristic world of class based OO. And it provided me with a common vocabulary that would ease communication with coworkers.
These days I find the GoF patterns to be a bit dated. A lot of it had to do with patching the shortcomings with the popular languages of the day; mostly C++ but Java had the same kinds of issues. A good deal of them could be paraphrased as "alas, functions are not 1st class citizens but as a workaround let's wrap them in an object" or "alas, our language does not readily support the common need to do X, so here is how to implement X ourselves". Someone once noted that design patterns are really language smells and I think that hit the nail on the head. The GoF patterns are really a catalog of the pain points of C++ (and similar strongly typed, class based OO languages).
In recent years I've had the pleasure of working in Javascript. Does GoF apply to Javascript? Not really. Does Javascript have design patterns? I'd say yes but there are fewer of them. Promises are really a design pattern to ease the pain of working with callbacks. Using function scope to hide private variables is a design pattern to deal with the lack of having private sections of the code. The module systems such as CommonJS deal with the lack of language level packages, and also provides a solution to isolating code in a well defined way.
Bottom line is that design patterns are not universal in any way; they are very specific to the type of language that they deal with. Also: Language designers better pay attention to the design patterns which evolve over time since each one points to a potential improvement of the language itself.
Being new to Java at that time, the GoF patterns were also a very useful crutch to me when trying to learn to "walk" in the bright and futuristic world of class based OO. And it provided me with a common vocabulary that would ease communication with coworkers.
These days I find the GoF patterns to be a bit dated. A lot of it had to do with patching the shortcomings with the popular languages of the day; mostly C++ but Java had the same kinds of issues. A good deal of them could be paraphrased as "alas, functions are not 1st class citizens but as a workaround let's wrap them in an object" or "alas, our language does not readily support the common need to do X, so here is how to implement X ourselves". Someone once noted that design patterns are really language smells and I think that hit the nail on the head. The GoF patterns are really a catalog of the pain points of C++ (and similar strongly typed, class based OO languages).
In recent years I've had the pleasure of working in Javascript. Does GoF apply to Javascript? Not really. Does Javascript have design patterns? I'd say yes but there are fewer of them. Promises are really a design pattern to ease the pain of working with callbacks. Using function scope to hide private variables is a design pattern to deal with the lack of having private sections of the code. The module systems such as CommonJS deal with the lack of language level packages, and also provides a solution to isolating code in a well defined way.
Bottom line is that design patterns are not universal in any way; they are very specific to the type of language that they deal with. Also: Language designers better pay attention to the design patterns which evolve over time since each one points to a potential improvement of the language itself.