There is one area in which knowing something about category theory actually changes the way you program in Haskell. I think that’s once you learn about algebras and coalgebras, because that gives you this level of abstraction in which you stop doing things using recursion. The first big problem when people learn Haskell or other functional language is recursion, right? Especially when you come from C++ or traditional languages, right? You always write loops, right? And you think in terms of loops, I have to iterate, iterate, right? How do I iterate in Haskell? Well, you do recursion, but recursion is kind of like a weird way of thinking when you have to sort of assume that you already solved a problem and then you have to do one more step to finish it. And it’s not natural. In iteration, you just do one step at a time, and then next step, and then next step, and then step. In recursion, you have to assume that you’ve done it already, right? I haven’t done it yet, but let’s assume that I’ve done it and now I need one more final step, right? So this is hard. But then when you learn about algebras and things like catamorphisms, anamorphisms, all this stuff, you suddenly think, “Oh, I don’t have to think recursively. I can think holistically.” It’s a data structure. I’m looking at this whole data structure and I’m applying a transformation to this whole data structure all at once. And this is so powerful. Bartosz Milewski, https://haskell.foundation/podcast/30/, 27:14
However, much in the same way that music is not a set of instruments, functional programming is not a set of abstractions that we need to learn and memorize. Functional programming is an approach to solving computational problems. Many of the abstractions that you do read about are ways to apply this approach to new problems, or problems that were difficult to solve without reaching for more traditional programming methods. But the essence, the core, of what functional programming is about is mostly unchanged. In the preface to the book Burge writes (emphasis mine): "The main emphasis [of this book] is placed on those parts of the language, namely expressions, that denote the end results sought from the computer, rather than on the instructions which the machine must follow in order to achieve the results. The main thesis of this book is that, in many cases, this emphasis on expressions as opposed to mechanisms simplifies and improves the task of programming.” The above will be familiar to anyone who has had the good fortune of taking a well designed functional programming course. This is the paradigm shift that sometimes makes functional programming hard to learn for those that are used to other methods of programming. Expressions over mechanisms. Jose Calderon, http://jmct.cc/intro/index.html
Even if you are using functions/methods that are usually met in the functional programming paradigm, if you think about the implementation details (e.g. mentally iterating over arrays or worrying about how map executes under the hood), you are in the imperative mindset. With functional programming and a declarative mindset, the focus should be on the intent of the operation applied.
Aris Goudouras
Importantly, it’s not that in functional programming we don’t deal with mechanisms or low-level constructs. It’s the emphasis that changes in how we attack the problem (from the instructions to the end results) that makes the difference.
Aris Goudouras
Interestingly, Burge’s and Calderon’s perspective is much different than Milewski’s, who focuses on the abstractions and category theory part.
Aris Goudouras
I think Burge (and Calderon) here endorse the declarative style manifested in the expressions. But I don’t really understand at this point why FP expressions are declarative in FP (especially with ones like Do notation, we really have the opposite).