It’s interesting to me how many authors and users of these libraries say similar to “it’s not necessary to understand category theory”. If so, then why refer to it’s concepts in type signatures? Because it’s helpful for program design? If so, then I should know more about it when designing my own programs. It’s contradictory - doing one thing and saying another.
This is a good point. I don’t think it’s contradictory, and I’ll try to explain why.
I am very confident saying that it’s not necessary to understand category theory to make use of the Functor-Applicative-Monad hierarchy in languages like Haskell or PureScript, because I personally have been writing programs making use of this hierarchy since around 2013, whereas I only really got my head around what a Functor really is (in the category theory sense) last year, when I took a CT course during my maths degree. I’m sure I’m not the only one who was making use of this hierarchy without having studied the ideas behind it, too.
The key point is that a PureScript or Haskell Functor is a very specific example of the category theoretical functor. In category theory, if C and D are categories, a functor F : C -> D is a mapping between them; each object A in C is mapped to an object F(A) in D, and each arrow f : A -> B in C is mapped to an arrow F(f) : F(A) -> F(B) in D, such that F(f ∘ f’) = F(f) ∘ F(f’) for any pair of arrows f, f’ (provided that they are compatible i.e. it makes sense to compose them), and also F(id) = id. Functors for which the source and target category are the same are called endofunctors. So if F : C -> C, we would say that F is an endofunctor on C.
Haskellers often speak of the category Hask, whose objects are the Haskell types of kind * (aka Type) and whose arrows are Haskell functions. A Haskell Functor, therefore, is (more or less) an endofunctor on Hask.
Of all the functors which could exist, the functors which we can realise as instances of Functor are but a very restricted subset. To make use of the hierarchy in Haskell or PureScript, you only need to get your head around this subset. This is a much easier task than properly getting your head around the much wider concept of Functor in the CT sense; there are many examples of category theoretic functors which will at first seem like they have absolutely nothing in common with Haskell functors. For example, there are a few structures from abstract algebra which can be regarded as categories, such as monoids, groups, and posets. Functors between two monoids regarded as categories amount to monoid homomorphisms, and similarly, functors between groups and posets regarded as categories amount to group homomorphisms and order-preserving maps respectively.
You could argue that the Haskell Functor should really be called HaskEndofunctor… but you can probably immediately see why we don’t call it that.
To address the question of why we refer to its concepts in type signatures: because even though you don’t need to get your head around category theory to use them, it’s useful to indicate that this is where these concepts have come from in case you do want to dig deeper.
Category theory can certainly be useful for program design; the Functor-Applicative-Monad hierarchy itself is a great example. I think this talk is a great example too:
However, studying CT is far from the only way to improve your program design skills. For most people, there are going to be many other things you can study which will be more effective in improving your skill in designing programs, in terms of the investment / payoff ratio.
