137

I'm learning Haskell and I'm fascinated by the language. However I have no serious math or CS background. But I am an experienced software programmer.

I want to learn category theory so I can become better at Haskell.

Which topics in category theory should I learn to provide a good basis for understanding Haskell?

Raphael
  • 72,336
  • 29
  • 179
  • 389

7 Answers7

134

In a previous answer in the Theoretical Computer Science site, I said that category theory is the "foundation" for type theory. Here, I would like to say something stronger. Category theory is type theory. Conversely, type theory is category theory. Let me expand on these points.

Category theory is type theory

In any typed formal language, and even in normal mathematics using informal notation, we end up declaring functions with types $f : A \to B$. Implicit in writing that is the idea that $A$ and $B$ are some things called "types" and $f$ is a "function" from one type to another. Category theory is the algebraic theory of such "types" and "functions". (Officially, category theory calls them "objects" and "morphisms" so as to avoid treading on the set-theoretic toes of the traditionalists, but increasingly I see category theorists throwing such caution to the wind and using the more intuitive terms: "type" and "function". But, be prepared for protests from the traditionalists when you do so.)

We have all been brought up on set theory from high school onwards. So, we are used to thinking of types such as $A$ and $B$ as sets, and functions such as $f$ as set-theoretic mappings. If you never thought of them that way, you are in good shape. You have escaped set-theoretic brain-washing. Category theory says that there are many kinds of types and many kinds of functions. So, the idea of types as sets is limiting. Instead, category theory axiomatizes types and functions in an algebraic way. Basically, that is what category theory is. A theory of types and functions. It does get quite sophisticated, involving high levels of abstraction. But, if you can learn it, you will acquire a deep understanding of types and functions.

Type theory is category theory

By "type theory," I mean any kind of typed formal language, based on rigid rules of term-formation which make sure that everything type checks. It turns out that, whenever we work in such a language, we are working in a category-theoretic structure. Even if we use set-theoretic notations and think set-theoretically, still we end up writing stuff that makes sense categorically. That is an amazing fact.

Historically, Dana Scott may have been the first to realize this. He worked on producing semantic models of programming languages based on typed (and untyped) lambda calculus. The traditional set-theoretic models were inadequate for this purpose, because programming languages involve unrestricted recursion which set theory lacks. Scott invented a series of semantic models that captured programming phenomena, and came to the realization that typed lambda calculus exactly represented a class of categories called cartesian closed categories. There are plenty of cartesian closed categories that are not "set-theoretic". But typed lambda calculus applies to all of them equally. Scott wrote a nice essay called "Relating theories of lambda calculus" explaining what is going on, parts of which seem to be available on the web. The original article was published in a volume called "To H. B. Curry: Essays on Combinatory Logic, Lambda Calculus and Formalism", Academic Press, 1980. Berry and Curien came to the same realization, probably independently. They defined a categorical abstract machine (CAM) to use these ideas in implementing functional languages, and the language they implemented was called "CAML" which is the underlying framework of Microsoft's F#.

Standard type constructors like $\times$, $\to$, $List$ etc. are functors. That means that they not only map types to types, but also functions between types to functions between types. Polymorphic functions preserve all such functions resulting from functor actions. Category theory was invented in 1950's by Eilenberg and MacLane precisely to formalize the concept of polymorphic functions. They called them "natural transformations", "natural" because they are the only ones that you can write in a type-correct way using type variables. So, one might say that category theory was invented precisely to formalize polymorphic programming languages, even before programming languages came into being!

A set-theoretic traditionalist has no knowledge of the functors and natural transformations that are going on under the surface when he uses set-theoretic notations. But, as long as he is using the type system faithfully, he is really doing categorical constructions without being aware of them.

All said and done, category theory is the quintessential mathematical theory of types and functions. So, all programmers can benefit from learning a bit of category theory, especially functional programmers. Unfortunately, there do not seem to be any text books on category theory targeted at programmers specifically. The "category theory for computer science" books are typically targeted at theoretical computer science students/researchers. The book by Benjamin Pierce, Basic category theory for computer scientists is perhaps the most readable of them.

However, there are plenty of resources on the web, which are targeted at programmers. The Haskellwiki page can be a good starting point. At the Midlands Graduate School, we have lectures on category theory (among others). Graham Hutton's course was pegged as a "beginner" course, and mine was pegged as an "advanced" course. But both of them cover essentially the same content, going to different depths. University of Chalmers has a nice resource page on books and lecture notes from around the world. The enthusiastic blog site of "sigfpe" also provides a lot of good intuitions from a programmer's point of view.

The basic topics you would want to learn are:

  • definition of categories, and some examples of categories
  • functors, and examples of them
  • natural transformations, and examples of them
  • definitions of products, coproducts and exponents (function spaces), initial and terminal objects.
  • adjunctions
  • monads, algebras and Kleisli categories

My own lecture notes in the Midlands Graduate School covers all these topics except for the last one (monads). There are plenty of other resources available for monads these days. So that is not a big loss.

The more mathematics you know, the easier it would be to learn category theory. Because category theory is a general theory of mathematical structures, it is helpful to know some examples to appreciate what the definitions mean. (When I learnt category theory, I had to make up my own examples using my knowledge of programming language semantics, because the standard text books only had mathematical examples, which I didn't know anything about.) Then came the brilliant book by Lambek and Scott called "Introduction to categorical logic" which related category theory to type systems (what they call "logic"). It is now possible to understand category theory just by relating it to type systems even without knowing a lot of examples. A lot of the resources I mentioned above use this approach to explain category theory.

Community
  • 1
Uday Reddy
  • 4,294
  • 1
  • 18
  • 23
  • i thought that if category theory were to make sense to a student, they should have some familiarity with abstract algebra. i.e. you should've seen an isomorphism to appreciate what this categories thing is about. and afaik there are some modern algebra texts that teach categories and algebra hand in hand from the start. are you saying that there are programming language examples, understandable to most programmers, that work just as well as the algebra examples in making category theory concrete? – Sasho Nikolov Aug 19 '12 at 18:53
  • @SashoNikolov Yes, the topics I listed in my post, viz., categories, functors, natural transformations, adjunctions and monads can be understood using just the category Set without any further knowledge of algebraic structures. Graham Hutton's and my notes from the Midlands Graduate School show how it can be done. Of course, knowing more mathematics helps. But it is not strictly necessary. I think we understand the connections with programming languages much better now. So we can explain it in our own terms. – Uday Reddy Aug 19 '12 at 21:58
  • (a) What is unrestricted recursion or why is it a problem for set-theoreticans? Can't you apply functions with defined domain and codomain as often as you want? Where is the restriction? (b) Is there a real reason why the category business gets mentioned with functional programming languages? Or is it just because it's conceptually closer to the definition of algorithms/lambda calculus? (c) Naive question: How are whole functional programming expressions (concatenations of functions) represented in category theory? Is it that one says this long concatenation equals some other morphism? – Nikolaj-K Oct 17 '12 at 09:58
  • @Nick Kidman. By "unrestricted recursion" I meant recursion where there are no restrictions on what arguments you can make recursive calls for. It does not in general define a (total) function in the set-theoretic sense. In set theory, you are only allowed to do primitive recursion, i.e., make recursive calls for "smaller" arguments. There is a large body of theory, called domain theory, in programming language semantics that deals with unrestricted recursion. – Uday Reddy Oct 23 '12 at 19:57
  • @Nick Kidman. The reason category theory gets mentioned in connection with functional programming is that category theory deals with types and functions, which are both of relevance to functional programming. People have also found that category-theoretic notions, e.g., monads, are useful for structuring functional programs. In the Midlands Gradaute School, you will find a course on "Advanced Functional Programming" which covers these issues. See, especially, the slides of lecture 3. – Uday Reddy Oct 23 '12 at 20:05
  • 3
    @UdayReddy I strongly disagree with your identification of category theory with type theory. Modern type theory is sustantially about types for concurrency processes, e.g. the theory tradition of session types. To the best of my knowledge there is no categorical understanding of such typing systems. – Martin Berger Jan 09 '13 at 03:34
  • 6
    @MartinBerger I think your interpretation of "type theory" is a bit narrow. However, I agree that a proper type-theoretic and category-theoretic understanding of session types is currently a good research challenge, one that I intend to spend time on. – Uday Reddy Jan 09 '13 at 07:07
  • @UdayReddy In what sense is my understanding of type theory too narrow? – Martin Berger Jan 09 '13 at 11:51
  • @UdayReddy: How do reconcile your claims that (a) category theory is type theory, type theory is category theory, with (b) that a category-theoretic understanding of session types is currently a good research challenge? Prima facie (b) would suggest that one cannot at this point claim (a) to be true. – Martin Berger Jan 09 '13 at 14:10
  • @UdayReddy You say a "proper type-theoretic [...] understanding of session types" is currently lacking. What do you mean by this? What makes a type-theory properly understood? – Martin Berger Jan 09 '13 at 14:18
  • @MartinBerger. When a type theory is fully developed, it brings out all the inherent structure of the types in various ways. The type rules have symmetries in terms of introduction and elimination rules. You get equivalences like $\beta$ and $\eta$, which represent how introductions and eliminations of type constructors cancel each other out. Girard's "Proofs and Types" has an excellent treatment of all these aspects. – Uday Reddy Jan 10 '13 at 00:31
  • @MartinBerger. Category theory generalizes and adds further depth to these symmetries found in plain type theory. There, we find that the $\beta$ and $\eta$ laws represent natural isomorphisms between hom-sets, typically forming adjunctions. The equivalence between typed lambda calculus and cartesian closed categories (which you can find in most semantics text books, e.g., Gunter's) illustrates these aspects. – Uday Reddy Jan 10 '13 at 00:39
  • @UdayReddy The typing rules for concurrent processes are more symmetric than the corresponding typing rules for functions, see e.g. [here](http://www.sussex.ac.uk/Users/mfb21/publications/lics01/index.html](here), here and especially here. That's why the late K. Honda advocated already over a decade ago to study $\lambda$-calculus by translation into $\pi$-calculus. – Martin Berger Jan 10 '13 at 00:45
  • @UdayReddy It is true that "category theory generalizes and adds further depth to these symmetries found in plain type theory". However, I don't believe that is the case when you move to the richer setting of concurrency theory. The reason is that concurrent programs (unlike functions) don't have a domain/codomain, moreover parallel composition does not hide the points of composition. Hence the composition operator of concurrency theory has no natural interpretation in category theory. That's why I believe that there is little hope that the neat correspondence between (continued below) – Martin Berger Jan 10 '13 at 00:51
  • typed lambda calculi and categories cannot extend to typed concurrent processes, and all attempts so far to do this have failed. So as far as I can see, your claim that categories and types are essentially the same thing is not currently supported by evidence. – Martin Berger Jan 10 '13 at 00:54
  • @UdayReddy And speaking of Girard, you are aware that the core of his ludics are an idiosyncratic variant of linear $\pi$-calculus and polarised linear logic is essentially the same thing as a variant of linear pi-calculus? – Martin Berger Jan 10 '13 at 00:59
  • @MartinBerger. Thanks for the references. I will be glad to see convincing evidence that category theory is not good enough for modelling certain kinds of things, perhaps concurrent processes. I will be even more glad if people could produce more general theories that could cover such phenomena. – Uday Reddy Jan 10 '13 at 14:17
  • @UdayReddy Of course category theory can "model" process theory, e.g. by using multi-categories and/or various hacks and tricks. Category theory is a very general formalism. The question is: do we learn anything new and neat from this? The promise of using category theory in computation was that it worked so well for purely functional programming, and this was because the key elements of FP can be mapped so neatly to the key elements of CT. I doubt that neatness prevails when moving to richer notions of computation, leaving a morass of encodings. – Martin Berger Jan 10 '13 at 14:57
  • 2
    @MartinBerger. To see how category theory applies to richer notions of computation, I invite you to look at how it has been applied to the theory of imperative programming and to games semantics (which again can encode imperative computations quite well). So, I don't believe that functional programming has a monopoly on category theory. – Uday Reddy Jan 10 '13 at 16:04
  • @UdayReddy Game semantics is not category theory, the categories of games involved are rather specific. And in order to accomodate simple state in a categorical analysis, additional structure needs to be added. That is difficult to reconcile with your claim that category theory and type theory are the same thing. – Martin Berger Jan 11 '13 at 16:51
  • @UdayReddy I have asked this follow-up question on Math Stackexchange: http://math.stackexchange.com/questions/284053/in-the-morphisms-are-functions-view-of-category-theory-how-are-poset-categories which stirred some interest. Perhaps you would like to comment? – Robin Green Jan 22 '13 at 21:25
  • @UdayReddy I'm a little late to the party, but I hope you can clear up a point. I understand how morphisms in category theory relate to functions (lambda abstractions) in simple type theory. But how does one model the introduction and elimination forms for the typing judgement in category theory? As far as I understand, these two logical notions are fundamental for understanding what a type is in the first place. – gardenhead Sep 28 '16 at 14:19
  • @gardenhead, a typing judgement $\Gamma \vdash M : \tau$ is treated as a morphism of type $\Gamma \to \tau$. The introduction and elimination rules map one or more such morphisms to another morphism, generically in all the types involved. They form natural transformations. – Uday Reddy Nov 21 '16 at 14:53
  • If type theory is category theory, then what are fibrations ? ;) – nicolas Jan 31 '17 at 21:03
  • 1
    @nicolas, fibrations are a way to do indexed categories, which model dependent types. Fibrations can also be viewed as a very general form of program logic, where $f : P \to Q$ means that $f$ maps $P$-satisfying values to $Q$-satisfying values. – Uday Reddy Mar 17 '17 at 17:59
  • 4
    "Unfortunately, there do not seem to be any text books on category theory targeted at programmers specifically." Such a "text book" now more-or-less exists in Bartosz Milewski's Category Theory for Programmers. Bartosz has also created an accompanying lecture series. – alx9r Jan 10 '19 at 15:46
  • I think it may be worthwhile to mention the distinction between static and dynamic typing. – reinierpost Feb 23 '23 at 14:10
  • While working on my book https://github.com/winitzki/sofp , I wrote down about 200 proofs in functional programming (proofs of all laws of most typeclasses and properties of various data types and constructions). In about 30% of those proofs I needed naturality laws, and also in about 30% of those proofs I needed functor laws. Of exactly zero usefulness were monad algebras, non-small categories, terminal objects, pullbacks/pushouts, (co)limits, topoi, Eilenberg-Moore categories, anything about adjoint functors, or that "monad is a monoid in the category of endofunctors". – winitzki Feb 27 '23 at 21:25
  • Are you able to write a more succinct version of this answer, as a "summary" section, perhaps? – Nike Dattani Mar 01 '23 at 14:52
36

Echoing @AJed advice, I recommend to turn your statement

I want to learn category theory so I can become better at Haskell.

on its head: learn Haskell, building on your programming intuition. Once you are an FP guru, it might be easier to pick up category theory (if you still care).

Category theory is simple for somebody with broad mathematical education (groups, rings, modules, vector spaces, topology etc). Lacking this background, category theory is nearly impenetrable. The beauty of category theory is that it unifies a lot of seemingly unrelated things (e.g. left adjoints of forgetful functors include free groups, universal enveloping algebras, Stone-Cech compactifications, abelianisations of groups, ...), and so reduces complexity. But if you are not familiar with the multiple examples that category theory unifies, category theory is just an additional layer of complexity that makes your life harder.

In my experience, learning is easier by building on things one already knows. As a software developer, you know a lot about programming, and Haskell programming is not that different from other programming, so my recommendation is to approach Haskell from a pragmatic programming point of view, ignoring category theory. The bit of category theory that is in Haskell, e.g. some support for monads, is much easier for a programmer to grasp without taking a detour via category theory. After all, monads are merely generalised composition (and you will have used monads in your programming practise already -- albeit without knowing you did), and Haskell doesn't really support monads for real, as it does not enforce the monadic laws.

Martin Berger
  • 8,308
  • 27
  • 45
  • 7
    No, to be honest Haskell really is that different from most other programming languages, to the point that getting past preconceived notions is often the biggest challenge. Experienced software developers seem to have more trouble than people who've never programmed before. – C. A. McCann Jan 09 '13 at 14:31
  • 7
    @C.A.McCann I agree that some experienced programmes appear to have a hard time moving from e.g. Java or C# to Haskell, but I don't think it's because there's something fundamentally different about Haskell. I think it's in part because it appears to be different. The idea that you need to learn category theory in order to appreciate Haskell has probably prevented quite a few experienced software developers from achieving Haskell mastery. (Cf. why F# doesn't have monads.) I certainly find it hard to think of many Haskell features that don't also have resemblances in other languages. – Martin Berger Jan 09 '13 at 14:54
  • 6
    Knowing Category Theory might help a bit, but not all that much, and learning it is certainly much harder than learning Haskell. There are pretty fundamental differences compared to most languages (purity, non-strict evaluation, the type system), and removing all the CT terms doesn't make these any more familiar. On the other hand, learning Haskell motivates some people to learn some CT, because the ideas borrowed are useful. F#'s limited type system and avoidance of a perfectly good existing term are flaws, not features. – C. A. McCann Jan 09 '13 at 15:02
  • @C.A.McCann I agree with your first sentence. Lot's of other languages have types, including higher order types, parametric polymorphism etc. Purity is the absence of effects and immediately grasped, moreover Haskell does have impurities, state, assignment etc. The only true novelty in Haskell here is that purity can be enforced by types. Regarding monads in F#, they are called workflows, or computational expressions (and they are called that so as to have a name less intimidating to working programmers). – Martin Berger Jan 09 '13 at 15:13
  • 1
    I don't know of any language other than Scala with a type system really comparable to Haskell's. From empirical observation, purity is not immediately grasped, and non-strict evaluation (which you skipped over) is even harder. Finally, I am a working programmer and I dispute that anyone in the field is going to be intimidated by a name. The software development industry is full of opaque jargon already. Also, F#'s type system cannot express monads directly--computation expressions are not first class, which limits their use significantly. – C. A. McCann Jan 09 '13 at 16:28
  • @C.A.McCann We are talking about learning a languages. I do not recommend that learners start at the deep end with all the complicated RankNTypes, TemplateHaskell and what have you enabled. I suggest to start learing Haskell using a small core and then, as learning progresses, gradually to introduce harder stuff. This small core his a fairly conventional language with one exception, that effects are a bit weird. Everything else is highly familiar to every working programmer, and different only on the syntactic surface. (Continued below.) – Martin Berger Jan 09 '13 at 23:59
  • 2
    CBN is also conceptually easy, for example by analogy with thunking, a concept that most working programmers will have used before. Purity is something that every working programmer understands. Haskell is used in undergraduate education in the UK. When my students ask me how to get into functional programming, I often recommend learning Haskell first, but students are intimidated by its reputation, as was the originator of the question. I believe the main reason for this is Haskell's association with category theory. – Martin Berger Jan 10 '13 at 00:02
32

I'm going to try and keep it short and sweet. There is an informal correspondence between Haskell programs and certain classes of categories, which can be made more formal with some work. This correspondence is known as the Curry-Howard-Lambek correspondence and relates:

  1. Haskell types with objects of the category
  2. Terms of type $A\rightarrow B$ with morphisms $f\colon A\rightarrow B$ (note the similar notations)
  3. Algebraic datatypes with initial objects
  4. Type constructors with functors
  5. etc

The list goes on and on, but one crucial point is that you can define things like monads and algebras in category theory and come up with notions that are both useful to mathematicians but also pervasive in the practice of Haskell programming.

I'm not sure which book to recommend, as I haven't found a completely satisfactory introductory book on categories for computer scientists. You can try Categories, Types and Structues by Asperti and Longo. The idea is to learn basic definitions up to adjunctions, and then maybe try and read some of the excellent blogs out there to try and understand these concepts.

cody
  • 8,184
  • 29
  • 62
  • 1
    "come up with notions that are both useful to mathematicians but also pervasive in the practice of Haskell programming" -- can you give an example, or would that require too much prior knowledge? – Raphael Aug 11 '12 at 11:08
  • 8
    @Raphael: Monads. Arrows. Algebras. Coalgebras. – Dave Clarke Aug 11 '12 at 12:10
  • 7
    Functors, duality, the Kleisli category, the Yoneda lemma... – cody Aug 12 '12 at 09:25
  • 5
    Cartesion closed categories. Currying. – Dave Clarke Aug 12 '12 at 18:04
  • 1
    Point taken. I was thinking more of a presentation that would be accessible to somebody not familiar with category theory, though, that is explicitly laying out the construction/analogy. (The mere statement of the things does not show the layman anything.) – Raphael Aug 16 '12 at 08:46
  • I'm not 100% sure of what you're looking for, but here are some slides of Paul-André-Méliès that derive natural equational laws for the state monad using the categorical notion of Algebras and Monoidal categories:

    http://www.pps.univ-paris-diderot.fr/~mellies/mpri/mpri-ens/ens-mellies-cours-5.pdf

    He uses this caractersation to construct a state monad with union of states in a natural way...

     – cody Aug 18 '12 at 20:39
  • 2
    "An introduction to Category Theory for Software Engineers", http://www.cs.toronto.edu/~sme/presentations/cat101.pdf – Vladimir Alexiev Oct 03 '14 at 10:18
15

A short answer: no [but this is only an opinion]

Don't go to Category Theory or any other theoretical domain to become good in Haskell. Learn functional programming techniques, such as tail recursion, map, reduce, and others. Read as much code as you can. Implement as many ideas as you can. If you have issues, read and read.

If you want a good theoretical reference to learn Haskell and other functional programming paradigms then have a look at: An Introduction to Functional Programming Through Lambda Calculus, Greg Michaelson (available online). ... There are other similar books.

Glorfindel
  • 752
  • 1
  • 9
  • 20
AJed
  • 2,422
  • 18
  • 24
  • 2
    I raise an eyebrow at this, because "tail recursion" is usually not important to programming in Haskell due to laziness. Nevertheless, "learn by doing" is almost always good advice. – Dan Burton Oct 30 '13 at 16:57
  • @DanBurton .. interesting observation. Let's say then, instead of Haskell, learn erlang or scheme :). [I am not an expert in Haskell, I just picked it because it sounds cool] – AJed Oct 30 '13 at 22:38
  • +1 mainly because of the first sentence, especially when compared to the first two answers which have far more upvotes. – Nike Dattani Mar 01 '23 at 14:54
3

Category theory is not a good basis for understanding Haskell. Category theory has certain but limited use for learning functional programming and in actual practice of functional programming. I recently made a presentation to answer the question "What did category theory ever do for us (functional programmers)". See https://www.youtube.com/watch?v=Zau8CxsfxOo

Summary of the talk:

  • Functional programmers do not require category theory in order to master the main features and design patterns that FP uses to write better code. For example, one can (and should) first learn how to use monads, functors, map/filter/fold, pattern matching, recursive algebraic data types, etc., in a concrete programming language with specific examples. Category theory will not help master these techniques even though the words "functor" and "monad" originally come from category theory.
  • At a certain point, programmers will see examples of typeclasses with laws, and understand why those laws are important in practice.
  • There will be lots of different laws. To make some order and system among those laws, we can formulate the laws as a generalized "lifting" type signature with "twisted" function types. At this point, it becomes useful to talk about categories, morphisms, and functors.
  • We can then use the definitions of category and functor as generalizations that explain the laws of functors, contrafunctors, filterable functors, filterable contrafunctors, monads, applicative functors, applicative contrafunctors, comonads, and perhaps other type classes.
  • I show some examples of categories that are used to describe functors, monads, applicatives, and filterable functors.
  • I cover filterable functors in more detail, with backdrop of category theory, because filterable functors are rarely explained as a separate typeclass.
  • Another example where category theory is useful: "type constructor libraries", i.e. libraries with functions parameterized by a type constructor. Examples of these are free functor / free monad / etc., and Church encoding of types (including recursive type constructors, e.g. the Church encoding of a free monad). Programmers who need to implement these libraries will need to understand how these constructions are defined and what laws need to hold. Category theory provides some limited guidance about that.
  • Conclusion 1: programmers need to learn functional programming and not category theory. The special knowledge required in functional programming (e.g., how to implement and use a free applicative functor in your programming language) is not going to be covered by any book in category theory.
  • Conclusion 2: basic definitions of category theory (category, functor, natural transformation) are useful as condensed formulations of general laws for a number of typeclasses. Unless a programmer has experience dealing with all the different laws of those typeclasses, it is unlikely that an appreciation of category theory will be of much help. Even for advanced programmers who are working with high-level type constructor libraries, a study of category theory is unlikely to be of any use beyond a few basic concepts and definitions (category, functor, natural transformation, monoid, initial object, Yoneda identities, F-algebra).
  • Conclusion 3: knowledge of category theory will not help us derive or prove laws for specific typeclasses, and will not help us implement those typeclasses correctly in code. The reason is that category theory is so general that it only talks about laws that apply generally to a large number of very different typeclasses (functor, monad, filterable functor, applicative functor, pointed functor, contravariant functor, etc.). For practical coding, e.g. to verify that our implementation of a specific monad is lawful, we need to learn not category theory but the techniques of symbolic derivation and proof.

I am writing a new free textbook ("Science of Functional Programming", https://github.com/winitzki/sofp) to develop and explain these techniques with practical programmers in mind. My book is going to be very light on category theory, and I'm not going to use any advanced abstract concepts unless there is a significant gain for practical work. Having written down several hundred step-by-step proofs, I have found what derivation techniques are useful and what definitions from category theory are helpful when proving the theoretical properties of practically relevant code.

Examples of category theory knowledge that has, so far, proved to be unnecessary and not useful:

  • monad is a monoid in the category of endofunctors
  • any monad comes from a pair of adjoint functors
  • a free monad comes from the free/forgetful functor adjunction

In contrast, naturality laws are used in at least 30% of all proofs, and the functor composition law is also used in at least 30% of proofs. This shows the importance of learning the definitions of functors and natural transformations and getting some intuition about how to use those notions for programming.

winitzki
  • 281
  • 1
  • 8
2

Here is a (long) blog post, that gives motivation on how category theory ideas are relevant for practical programming: http://cdsmith.wordpress.com/2012/04/18/why-do-monads-matter/

Sampo Smolander
  • 129
  • 1
0

Category theory is a very sophisticated branch of mathematics and mastering it will unify most of your previous learnings by making them instances of same abstract objects. So it is very useful and very intuitive. But it is vast and broad, and you will find yourself in a plenty of new concepts that will don't even know which one is suitable for your needs and which one you should skip. So your purposeful approach needs choice among concepts, otherwise mastering in it inevitably needs long time and is really not a self study domain.

By the way, I suggest a very well start point for your purpose to be here.

shvahabi
  • 121
  • 1
  • This doesn't really answer the question: is it useful for learning functional programming? Which topics in category theory are useful for Haskell? – David Richerby Mar 06 '15 at 22:50
  • Of course it is useful, actually without category theory you will stuck at just very simple functional programming. But the investment in terms of time and effort may not justify its use in most projects. You can do lot's of things with functional programming without diving into advanced concepts. I myself used FP for more than 2 years, then for doing advanced things I started to learn category theory. For Haskell I suggest start with Bartosz Milewski's book. – shvahabi Mar 15 '22 at 11:46