But both those things are Monads. They follow the Monad laws, the conform to a certain Monad interface, they both have bind and return, they behave like Monads.

To me the problem with using "pattern" is that it suggests a relationship when there's none, other than all of them being techniques that were presented in the same book.

Prematurely naming them also prevented other people from finding better names. For example, other techniques that are in the same idea-space, such as "Inversion of Control" and "Dependency Injection" don't need the "pattern" suffix, for example, but are still understandable.

Naming stuff is ok. I understand this. It's done in every field.

But calling the "naming of things" a "design pattern" is pretentious. Nobody calls Monads the "Monad pattern" and categorizes it as a sub field of "design patterns."

It's just like how we abstract the concept of getting into a car and commanding the car under the word "driving." That's fine. What's wrong is if We called it the "driving pattern" and place it an area of study within the automobile field called "design patterns."

Imagine if some expert race driver publishes a driving book called "Design patterns" then with an analogy relates it to architecture. Why not just call the book "Driving techniques" and eschew the useless analogy?

I'll tell you why the GoF did this. Because "Design patterns" sounds more academic, and the catharsis of realizing the analogy between architecture and programming techniques inflates the perception of what these concepts actually are. In the end these are just programming tricks or techniques.