3 ms·

Here's a clearer version of the paper[0]. This paper[1] is a good way for object-oriented programmers to understand why functional programmers care about these

Here's a clearer version of the paper[0]. This paper[1] is a good way for object-oriented programmers to understand why functional programmers care about these higher order abstractions. The goal is not so different from OOP, which is about structuring programs as reusable components (AKA design patterns). The difference of course is that one doesn't need to resort to diagrams and prose, instead they can be written directly in the programming language. Relatedly, one of my favorite books in functional programming is Algebra of Programming[2], which is about treating programs as an algebra that can be manipulated as easy (with practice) as algebraic expressions in math. The book solves various problems through program derivation, for instance solving the maximum subsegment problem by refining a naïve spec, deriving sorting algorithms, greedy algorithms, dynamic programming and thinning algorithms. This draft book[3] has similar content to the earlier chapters of AoP but is far more accessible. The downside of AoP is that I had to resort to reading it with a math professor to understand it. [0] https://maartenfokkinga.github.io/utwente/mmf91m.pdf https://maartenfokkinga.github.io/utwente/mmf91m.pdf [1] http://www.cs.ox.ac.uk/jeremy.gibbons/publications/hodgp.pdf http://www.cs.ox.ac.uk/jeremy.gibbons/publications/hodgp.pdf [2] https://themattchan.com/docs/algprog.pdf https://themattchan.com/docs/algprog.pdf [3] http://www4.di.uminho.pt/~jno/ps/pdbc.pdf http://www4.di.uminho.pt/~jno/ps/pdbc.pdf

misja111 6y ago
>> 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.
jmeister 6y ago
Thanks for these awesome references!
- scythmic_waves 6y ago
  Seconded!

misja111 6y ago

>> 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.

jmeister 6y ago

Thanks for these awesome references!

scythmic_waves 6y ago
Seconded!