4 ms·
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 func
by piva00 6y 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.
- mgarus 6y agoThis 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 https://www.youtube.com/watch?v=6mTbuzafcII
- closeparen 6y agoIf 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.