You just wanted some data? "Flyweight". You just wanted some functions? "Strategy". etc.
That is, I believe Alexander's version of design patterns would have things like "Intention Revealing Names" and code reviews focusing on "Clarity, Consistency, and Correctness (in that order)"--things that help subsequent developors live in and enjoy the code and design.
GoF approaches from the "building" side since it was created by and for programmers. Another way of thinking about this is that GoF is describing the experience of the design as a developer having to "inhabit" it, rather than a user's experience of the same.
That's why Alexander is not a particularly useful book for builders, since it focuses on the user's experience of the design when inhabiting it, rather than the constructors' experience of the same design when creating or modifying it.
A version of GoF that focused on the user experience would be a completely different book than the one we know.
Some people say that GoF patterns are just a way to cover up for OOP-centric language shortcomings.
Multiparadigm languages end up with lots of patterns you need to learn, because while multiparadigm languages may support many approaches to a given problem, generally there are definitely better and worse approaches, specific to the language in question, and between the number of options, the subtly of their implementation details and how those interact with the problem, and the specific preferences of the language itself (because all multiparadigm languages still have preferences), it can take a multiparadigm language community a decade to work out the best pattern for a given task. The existence of many options inevitably expands the number of wrong options, or if you prefer, "distinctly suboptimal" options, as well.
25 years later it still isn't (joking... kind of)
Back then I was a young innocent programming soul trying to reconcile C++ and GoF and UML and all that. And Modern C++ Design. And const here const there const copy constructor by reference.
Anyway. I like vanilla C. And Go at times.
I realized I was suffering from severe Stockholm Syndrome. Node.js was just.... so gd easy to do anything in. Maybe too easy (a la leftpad), but build/deploy cycles were instantaneous, adding new libraries was easy- again maybe too easy, JS has a tiny fraction of the footguns and you don't have to know them all to write code that isn't going to blow up on you or cause memory leaks and performance issues.
Python... was the same. I have even taken some dives into Java, and while I don't love the architectural monuments Java devs tend to produce, its still less of a hassle than C++.
I was so happy when there was a move towards templates and data oriented design and the priests of OOP were getting knocked off their pedestals- for a period you were at risk of getting shunned for not kneeling at the gods of OOP and the GOF book and UML diagrams.
I remember arguing for years with my father (also a programmer) about him writing either vanilla C, or writing C++ in (what would become) the data-oriented style.
...and look at me now!
I collect things in arrays, with no objects, preferrably in pure C. No classes, no objects, just arrays and transforming functions everywhere.