Comment by piva00
5 years ago
Patterns are commonly (but not only) symptoms of some failure of features on the language but at the same time they are just vocabulary.
Patterns exist in functional programming as well, any map/reduce operation is a pattern, any monad is a pattern. It's a proven way to achieve a goal, it's easy to compartmentalise under a moniker and refer to the whole repeatable chunk with a name.
Unfortunately a lot of people only learn how to properly apply design patterns after doing it wrong and/or overdoing it (mea culpa here!). It's easy to spot the bad smells after you've been burnt 2-3 times.
If map and reduce were design patterns, you’d be writing out the iteration bits every time you used them. Instead map and reduce are abstractions, and you only have to plug in your unique functions and values.
piva00 probably meant that implementing map and reduce for a data structure, rather than the use of them, is a design pattern.
That was my point, thanks for clarifying it :)
This reminds me of a talk by Rich Hickey [0], where he introduces the Transducer pattern, which is actually an abstraction for map/reduce/fold/filter etc.
(But I'm not trying to invalidate your claim that patterns exist in FP in general, only that specific case. Afaik, the Transducer abstraction isn't even widely-known nor used.)
[0]: https://www.youtube.com/watch?v=6mTbuzafcII