> Currently it looks like "use this design pattern because mathematics".
I've only recently gotten into FP, but to be honest, I prefer that to "use this design pattern, because design patterns", which is how things usually go, particularly in OOP. A lot of the "theory" in imperative programming seems four steps removed from the underlying theory (to the point where you can't really trace patterns to their underlying theoretical reasoning).
Sure, that often makes is easier to understand and utilize. To me, however, after 8 years of that, it's pretty sobering to start realizing just how much of your repertoire is cargo culting.
I would also argue that there is a huge difference in how the two worlds use, or even understand, design patterns. FP often puts you through the trouble of going back to basics (yes, sometimes even mathematical basics) and that can take enormous amounts of and effort. That's a level of discomfort and slowness I have come to appreciate.
I've only recently gotten into FP, but to be honest, I prefer that to "use this design pattern, because design patterns", which is how things usually go, particularly in OOP. A lot of the "theory" in imperative programming seems four steps removed from the underlying theory (to the point where you can't really trace patterns to their underlying theoretical reasoning).
Sure, that often makes is easier to understand and utilize. To me, however, after 8 years of that, it's pretty sobering to start realizing just how much of your repertoire is cargo culting.
I would also argue that there is a huge difference in how the two worlds use, or even understand, design patterns. FP often puts you through the trouble of going back to basics (yes, sometimes even mathematical basics) and that can take enormous amounts of and effort. That's a level of discomfort and slowness I have come to appreciate.