A special strawman in the article is the obliviousness to technical complexity that builds on the lack of historical awareness.
Given the same evergreen problems, a solution that is built-in in the language or trivial isn't worth writing up as a design pattern, as the GoF book itself explains in its introduction; but in the C++, Smalltalk, Java that were available 30 years ago a relatively uninteresting design that reduces to creating easily and passing around obviously some "first class function" in modern languages like Python was well worth teaching and analyzing because it had to involve objects, with incoming and outgoing pointers and lifetime concerns, classes to describe them, usually a hierarchy of further classes to use them properly.
> Good design is invisible. It’s not supposed to get in your way.
Design patterns are relevant for the challenging parts of the software where the programming language reaches its limits and good design becomes visible and non-obvious. Different languages have a different frontier of difficult uses and interesting techniques.
