This is a very hazardous false equivalence, and it gets trotted out every six months or so. There's an important difference between the items in those two sets. If I tell you, that say, this code only cares that some type argument is a Monoid, you know how to reason about it and come away with laws you can use to check if your code is correct without having to go down to the case-by-case instantiation of that code at every possible type. That doesn't happen if I tell you it is a Strategy. What are the laws of a Strategy? The Gang of Four sure as hell never told us any. So now I have to read the code anyways, and still reason through every possible instantiation of the types. I've gained nothing except additional onboarding time, and some vocabulary for smells and feelings. Now it did give us, for the time, a vocabulary that was better than what we had in the imperative world. It gave us a canonical reference chapter for each golden idea, complete with a smorgasbord of options to pick and choose between judiciously written so as to not offend anybody that their precious variant on the idea wouldn't fit the mold. But, ultimately, the GoF patterns hold for a narrow range of languages. And patterns are really about expressing thoughts your language is bad at letting you properly encode as a library. They more or less acknowledge that in the book itself. They are by definition code that some poor schmuck is stuck writing variants on over and over. But I can write a 'Monoid' and package it up and never rewrite that code again. Most consumers of it need never care too much about the details. You can know it is safe to foldMap with (at least for finite cases) as long as you trust the implementation to be correct to the claim of being a Monoid. Now, we do have _plenty_ of "real" design patterns in functional programming! * encouraging `higher-kinded` data to avoid having lots of copies of near identical structure * "boring" haskell so you don't have to teach so many new tricks and more of the language works * some folks like to newtype all sorts of things rather than rely on them being stringly typed. * all the machinery we use to manage masking for exceptions is right on the cusp of being a design pattern. I say that because we _do_ get to reuse the implementation that was written by God and/or @simonmar back at the dawn of time, but knowing when and why to use the mask idiom takes about the effort of reading one of the GoF chapters. * I gave a bigger laundry list here last time the oop design patterns vs. functional programming thing came up: xitter.cf/kmett/status/181610002… *tl;dr* FP isn't free of design patterns, but typeclasses aren't design patterns.