3 ms·

>> The goal is not so different from OOP, which is about structuring programs as reusable components (AKA design patterns) And it is exactly the overuse of de

>> The goal is not so different from OOP, which is about structuring programs as reusable components (AKA design patterns) And it is exactly the overuse of design patterns that is one of the reasons that OOP has become less popular over the years. I see a lot of similarities with FP there. Once you learn a new design pattern it opens your eyes to new and beautiful solutions for existing problems. And of course from then on you want to use it wherever you can. To repeat a cliché: If your latest tool is a hammer, every problem looks like a nail. This overuse of abstractions leads to software that is hard to understand and because of that, it actually becomes harder to maintain or extend, while the whole point of design patterns was to make it easier. This doesn't mean that design patterns, either in OOP or FP, are bad, no they still are really powerful but only if used when they are strictly needed; they should most of the time not be used to introduce some opportunity for reusability if reusability is currently not needed.

bollu 6y ago
Luckily, the nice thing about functional "design patterns" as invented by the haskell community always have mathematical laws attached to them. The advantage of having formal laws is that functional programmers can reason mathematically about their design patterns. This is completely different from the OOP case, where a "design pattern" is something someone found useful X number of times, with no rhyme or reason for structuring things this way. Which is why, in my opinion, it's so hard to talk about OOP design patterns beyond "it seems to fit". This is completely unlike the OOP community, where a design pattern has a poor spec written in english.
- siraben 6y ago
  Having learned FP's design patterns before OOP's, it was amusing to ask questions such as, "what are the laws for visitors/iterators/builders?" In the FP community, the laws for folds/unfolds/functors etc. are sacred, which make for very robust programs and well-behaved libraries.
  - Sharlin 6y ago
    It’s the difference between the engineer’s approach and a mathematician’s one. (Physicists, they just write FORTRAN.) To be fair, design patterns were quite explicitly introduced as ”these are things OO people seem to reinvent and converge on, so seemed worth documenting.”
siraben 6y ago
Yes, overuse of abstractions is a problem, however I'd argue from experience that using recursions schemes in FP allow us to be free from "the goto of FP", that is, direct recursion. You can of course still write programs in directly recursive style, then later replace them with a mathematically equivalent program that uses recursion schemes, which is essentially refactoring. Similarly, I can easily generalize a program by replacing, for instance, map on lists with fmap, and now it will work for any functor. I think what adds to the value of FP's abstractions is how they have mathematical (viz. categorical) laws in mind, which make them precise and elegant. Anyone know if the same can be said for design patterns? It requires more classes to be added, more boilerplate, which definitely adds to the complexity.
- siraben 6y ago
  Also, these laws are immensely valuable to compilers. The Haskell foldr/build rewrite rule allows for intermediate lists to be eliminated altogether[0], so you can write sum (map square [1..n]) and the compiler will remove the intermediate list altogether, putting a tail-recursive loop in the expression's place. [0] Paper on deforestation https://link.springer.com/content/pdf/10.1007%2F3-540-19027-9_23.pdf https://link.springer.com/content/pdf/10.1007%2F3-540-19027-...

bollu 6y ago

Luckily, the nice thing about functional "design patterns" as invented by the haskell community always have mathematical laws attached to them. The advantage of having formal laws is that functional programmers can reason mathematically about their design patterns. This is completely different from the OOP case, where a "design pattern" is something someone found useful X number of times, with no rhyme or reason for structuring things this way. Which is why, in my opinion, it's so hard to talk about OOP design patterns beyond "it seems to fit". This is completely unlike the OOP community, where a design pattern has a poor spec written in english.

siraben 6y ago
Having learned FP's design patterns before OOP's, it was amusing to ask questions such as, "what are the laws for visitors/iterators/builders?" In the FP community, the laws for folds/unfolds/functors etc. are sacred, which make for very robust programs and well-behaved libraries.
- Sharlin 6y ago
  It’s the difference between the engineer’s approach and a mathematician’s one. (Physicists, they just write FORTRAN.) To be fair, design patterns were quite explicitly introduced as ”these are things OO people seem to reinvent and converge on, so seemed worth documenting.”

siraben 6y ago

Yes, overuse of abstractions is a problem, however I'd argue from experience that using recursions schemes in FP allow us to be free from "the goto of FP", that is, direct recursion. You can of course still write programs in directly recursive style, then later replace them with a mathematically equivalent program that uses recursion schemes, which is essentially refactoring. Similarly, I can easily generalize a program by replacing, for instance, map on lists with fmap, and now it will work for any functor. I think what adds to the value of FP's abstractions is how they have mathematical (viz. categorical) laws in mind, which make them precise and elegant. Anyone know if the same can be said for design patterns? It requires more classes to be added, more boilerplate, which definitely adds to the complexity.

siraben 6y ago
Also, these laws are immensely valuable to compilers. The Haskell foldr/build rewrite rule allows for intermediate lists to be eliminated altogether[0], so you can write sum (map square [1..n]) and the compiler will remove the intermediate list altogether, putting a tail-recursive loop in the expression's place. [0] Paper on deforestation https://link.springer.com/content/pdf/10.1007%2F3-540-19027-9_23.pdf https://link.springer.com/content/pdf/10.1007%2F3-540-19027-...