7 ms·

Please Don't Learn Category Theory (2013)

54 points by psibi 13y ago

orlandob 13y ago
Linkbait trash. "Don't do this thing everybody says you should do. But I do and I like it."
- Aqwis 13y ago
  That's a very dishonest summary of the article. What he's actually saying is this: "Don't do this thing everybody says you should do, except if you're actually interested in the math."
  - andrewflnr 13y ago
    Then he really should have titled it, "You don't need to learn category theory", not the imperative "don't...". As it is, this is a textbook case of linkbait: choosing a dramatic title to get clicks.
bonemachine 13y ago
Finally someone has the courage to tell the Truth about CT. Next up: the idea that the notions of Monad, Functor, and Category (in whatever guise) are even needed or helpful to do strong FP.
- cnlwsu 13y ago
  I was able to be fairly effective (imho) in clojure/scala without knowing anything about fuzzyWuzzies, bananas, and cheerios. I felt learning about them becomes interesting though as you dig into the language more. Mostly as a curiosity thing... spend some time to "finally learn about monads" to see you've been using them the entire time.
- tjr 13y ago
  I like how he wrote a post a few days later, Learn You Some Category Theory: http://jozefg.bitbucket.org/posts/2013-10-22-category-theory-in-haskell.html http://jozefg.bitbucket.org/posts/2013-10-22-category-theory...
- freyrs3 13y ago
  Are they needed? No. Are they useful abstractions? Yes. Like most abstractions in Haskell the theory is always optional.
- nbouscal 13y ago
  Strictly speaking very little is needed. You can write everything in assembly if you'd like. Helpful, though? There's absolutely no question. Type classes like those you mentioned make programs more concise, more understandable* , and more general. All of those are good things. * Specifically, understandable to people who know the language and concepts. Trying to be understandable to everyone is a terrible idea. For example, Cucumber.
- dllthomas 13y ago
  I regularly miss Monad as an abstraction in my C code and Functor in my C#. They're just plain helpful, FP or not. Needed? Probably not, though a case could be made that monad is sufficiently helpful to deserve that title for dealing with sanely ordering IO in a lazy language.
rtfeldman 13y ago
> the people who designed Haskell decided they weren’t going to pretend they didn’t use math This is almost certainly the decision that has kept the most people from successfully learning Haskell. If you write "Appendable", many programmers go "oh, okay, got it." If you write "Monoid", many programmers go "yeeeah, I don't know if I have time to learn all this." This is either a perfectly acceptable cost of avoiding redefining the wheel, or a cautionary tale for future language developers, depending on your perspective.
- anaphor 13y ago
  It's not really Appendable though, because e.g. you can write a Monoid instance for various number-y things like Sum and Product.
  - srl 13y ago
    And you could write an Appendable instance for them as well, it would just fly in the face of what the word "append" means to most people. (Nitpick, of course.)
    - dllthomas 13y ago
      Sure, but is that more understandable than using "monoid"?
      - chilldream 13y ago
        Don't know enough to know that the current name is optimal, but at least "Monoid" correctly says to the initiated "you don't understand this yet." "Appendable" lies to you and says "you understand this" even if you don't.
        dllthomas 13y ago
        "Monoid" also has the advantage of being very searchable. First result on Google (from a private browser window) is the Wikipedia page with the snippet "In abstract algebra, a branch of mathematics, a monoid is an algebraic structure with a single associative binary operation and an identity element". DDG gives similar results, though the Doctor Who aliens are higher up...
lmm 13y ago
You need the words to be able to use Haskell. There are too many of them to learn otherwise. I have a similar experience with scalaz, where I tend to only spot useful things in the library after I've reimplemented them, because they don't have names that let me find them based on what they do. (Possibly the only benefit of a previous company that wouldn't let me use scalaz was that, in reimplementing it myself, I got to give the typeclasses sensible names like "CanFlatMap")
jfarmer 13y ago
The problem with being a programmer and learning category theory is two-fold. First, category theory is very abstract. Indeed, mathematicians often jokingly refer to category theory as "abstract nonsense." The story goes that Norman Steenrod, one of the creators of category theory, coined this term himself. So, category theory can be abstract even for mathematicians. Second, the "stuff" that category theory was built to abstract is highly mathematical and foreign to virtually every programmer who doesn't have a math background. What's worse, the bits of category theory that Haskell uses most frequently are typically not the bits of category theory that mathematicians use most frequently. When you put these together, it's very hard to connect the dots between "category theory", "category theory as Haskell uses it," and "Haskell as a typical Haskell programmer uses it." To build up to the bits of category theory that Haskell uses requires understanding things like categories, morphisms, functors, adjoint functors, natural transformations, adjunctions, and commutative diagrams, to name seven. Trying to understand these without understanding their (inherently mathematical) motivations would be a tiny nightmare — they'd feel like a bunch of disjoint facts and diagrams that are supposed to mean who-knows-what. And even if you get there, the categorial nature of monads in Haskell is not exactly apparent on the surface. Haskell exposes more programmer-friendly interfaces like "bind" that take some effort to translate into the language of category theory. A major motivator in the development of category theory, for example, was as a tool to explore the relationship between topological spaces and groups, a field of mathematics called algebraic topology (http://en.wikipedia.org/wiki/Algebraic_topology http://en.wikipedia.org/wiki/Algebraic_topology).
- Fasebook 13y ago
  What a ridiculous assertion. Category Theory and Chomsky Hierarchy are two easy to understand and key theories of Computer Science. If you don't have any understanding of these, you're not a professional programmer. Maybe it's "even abstract for mathematicians" should be "too abstract for detail oriented math nerds, but pretty easy to comprehend at a basic level"
  - jfarmer 13y ago
    I'm not sure what the Chomsky Hierarchy has to do with what we're talking about, but re: category theory, there's a difference between "understanding" and "familiarity." I agree that the definition of a category is not a hard thing to learn. However, can you give me, say, three non-trivial examples of categories you'd expect a "professional programmer" to know? How about three non-trivial examples of functors? If understanding category theory is a pre-requisite for being a professional programmer then 95% of the people I know who get paid to program aren't "professional programmers. You're just being silly. Or trolling. Probably trolling.
guard-of-terra 13y ago
With such a great number of people around me dabbling in Category Theory, I'm not sure it's worthwhile anyway. I don't like crowded areas. Maybe learn something useful but less hot - cryptography perhaps?
- KirinDave 13y ago
  Are you too cool for category theory? Fashion is a terrible reason to learn math, or to decide against learning it. Don't be a hipster.
badman_ting 13y ago
Makes sense if your goal is to use some particular language (in this case Haskell). But a lot of us don't necessarily need yet another programming language, whereas adding to our theoretical knowledge can be beneficial no matter what environment we're programming in.
saosebastiao 13y ago
I call mega-exponential-factorial-to-the-n-bullshit. I tried doing exactly that. You can't learn Haskell beyond superficial hello world apps without learning what a monad or functor are, because there aren't any substantial teaching materials that don't force you to understand it in order to continue learning, and all the common libraries require you to know how to use them because they are undocumented and have no examples. Can you use Haskell without understanding how those things work? Sure...if by "use" you mean you are limited to copied and pasted code snippets without an ability to understand what your code is doing, with the slightest change causing unintelligible compile errors.
- nilkn 13y ago
  My impression of the article was not that you don't need to know what monads and functors are, but rather that you don't need to understand them on the level of category theory. I think that's a true statement, if your interest is in simply writing software in Haskell and not in breaking new ground in the Haskell community (like writing the lens library itself).
- nbouscal 13y ago
  You have to learn what Monad and Functor are, but you do not by any means need to learn what a monad is, or what a functor is. To put it another way, you need to learn the Haskell type classes that have those names, but you do not need to learn the category theoretical constructs from which those names were taken. I believe this was the entire point of the article. The Haskell type classes are actually not too hard to learn at all, if you give it a bit of effort.
- tene 13y ago
  There's a significant difference between a wide understanding of category theory in general and understanding what a monad or a functor is used for in haskell. They're just type classes, nothing special. There's not all that much more to know about them besides their definition. I rather disagree that they are undocumented and have no examples. Section 6.3.6 in the haskell report 2010 defines the type class and provides examples: http://www.haskell.org/onlinereport/haskell2010/haskellch6.html#x13-1330006.3.6 http://www.haskell.org/onlinereport/haskell2010/haskellch6.h... See also, the typeclassopedia, which walks through a simple definition, many examples, and discusses general intuition: http://www.haskell.org/haskellwiki/Typeclassopedia#Monad http://www.haskell.org/haskellwiki/Typeclassopedia#Monad Perhaps I've misunderstood you, and maybe you mean that common libraries are undocumented and have no examples? That certainly hasn't been my experience; most libraries I've run into have plenty of documentation for me. Can you give me some examples? Yes, I agree that trying to write haskell without being able to understand simple type classes would be very difficult and confusing, but I disagree with what I understand the implied point to be, perhaps you could clarify this for me? I understand you to be saying here that you expect to be able to proficiently use a language with negligible understanding of how data types work in the language, or the common data types defined in the standard library? That sounds like nonsense to me, so I suspect I'm confused here; can you be a bit more explicit in your criticisms here?
rschmitty 13y ago
Side note from this submission is that I did learned you can host html like github https://confluence.atlassian.com/display/BITBUCKET/Publishing+a+Website+on+Bitbucket https://confluence.atlassian.com/display/BITBUCKET/Publishin... Nifty!
tikhonj 13y ago
A bit of a link-baity title. It's not that you shouldn't learn category theory, it's that you don't have to. Even if you want to program in Haskell. But is it worth learning on its own? Probably. At least the basics are. You'll get more insight into the design of languages like Haskell and ML and acquire a bunch of new abstractions which have a very good "power-to-weight" ration: that is, abstractions which are surprisingly general and expressive but also simple. The compromise, of course, is that these abstractions are really abstract--they do not admit good concrete explanations. At first, thinking about this sort of abstraction is difficult, but they become extremely powerful and convenient once you get used to them. Category theory also helps people design libraries. In a sense, category theory is focused on composition, which is obviously integral to writing good code. Additionally, some extremely useful constructs--like prisms from the lens library--were discovered largely thanks to category theory. Finally, category theory gives you a new perspective on programming. I find this very valuable because it gives me more than one way to think about whatever I'm working on. It's useful in the same way Curry-Howard is useful--in fact, there's a very natural extension of Curry-Howard to include categories with certain structure. So yeah: please don't feel you have to learn category theory, but consider learning it anyway.
- joe_the_user 13y ago
  But the alternative he proposes actually sounds more daunting than learning category theory: "In fact, try substituting Monad -> FuzzyWuzzy Functor -> Banana Category -> Cheerios" Sure, uh, all the other languages I've learned involved using opaque labels whose meaning I had to infer over time. No, that approach is for something like esthetic theory. All the languages I've learned used pretty concrete intuitive terms for their constructs, even the terms weren't really accurate. Having to manipulate a construct without the slightest hint to qualities sounds just maddening. Learning a programming language is hard enough that I think the learner needs terms that suggest they're dealing with something concrete even if they're not.
  - axman6 13y ago
    Then try Monad -> Sequenced Functor -> Mapable Category -> ... I don't know, I don't use it much (not that it doesn't have a nice understandable alternative name, I just don't know it) Monad and Functor are really quite simple classes to understand, and Tony Morris' 20 intermediate exercises listed in the article helped me greatly when trying to understand the concepts. I've been a haskell programmer for 6 years, and feel I know about zero cetrgory theory. It's never seemed to hurt me (except when Edward Kmett pipes up in IRC and I don't understand a word after that =)
ekidd 13y ago
This is a nice, short article which basically says, "You don't actually need to go learn a bunch of category theory if you want to learn Haskell, so please don't stress about it." Despite the title, it's not any kind of general argument that no programmer should learn category theory. Category theory is a strange branch of math—it's almost entirely definitions, with only a handful of interesting theorems. As far as I've been able to understand, category theory is a very abstract analogy between very different branches of math: abstract algebra, topology, mathematical logic and (here's the interesting part) the lambda calculus, via Cartesian closed categories. This analogy has interesting payoffs, especially for programming language designers and people trying to do seriously weird stuff. For example, let's imagine you have a value of type A, a function from type A to type B, and another function from B to C. But if you squint at these types right, it's the same as a logical system where A is given, A implies B, and B implies C. Now, it turns out we have automated theorem proving software that can take statements like this and figure out how to get from A to C (even in much more complicated situations). And it turns out the analogy between types and logic is sufficiently strong that you can actually use a theorem prover to write certain kinds of programs without any human intervention, given nothing but the type signatures of your functions. And this is not the only clever analogy lurking here: My favorite is the way that probability distributions can be mapped onto the lambda calculus. So, no, you don't need to know all this math to write Haskell programs. (Although some library authors are a little nuts, generally in a good way.) And yes, category theory is a weird branch of scarily-abstract math without many theorems, and Haskell only uses certain corners of category theory. Still, there are times when category theory will allow you to see how far-flung branches of math can be mapped tidily onto the lambda calculus. And that should be of interest to Lisp developers, at least.

54 points by psibi 13y ago

orlandob 13y ago

Linkbait trash. "Don't do this thing everybody says you should do. But I do and I like it."

Aqwis 13y ago
That's a very dishonest summary of the article. What he's actually saying is this: "Don't do this thing everybody says you should do, except if you're actually interested in the math."
- andrewflnr 13y ago
  Then he really should have titled it, "You don't need to learn category theory", not the imperative "don't...". As it is, this is a textbook case of linkbait: choosing a dramatic title to get clicks.

bonemachine 13y ago

Finally someone has the courage to tell the Truth about CT. Next up: the idea that the notions of Monad, Functor, and Category (in whatever guise) are even needed or helpful to do strong FP.

cnlwsu 13y ago
I was able to be fairly effective (imho) in clojure/scala without knowing anything about fuzzyWuzzies, bananas, and cheerios. I felt learning about them becomes interesting though as you dig into the language more. Mostly as a curiosity thing... spend some time to "finally learn about monads" to see you've been using them the entire time.
tjr 13y ago
I like how he wrote a post a few days later, Learn You Some Category Theory: http://jozefg.bitbucket.org/posts/2013-10-22-category-theory-in-haskell.html http://jozefg.bitbucket.org/posts/2013-10-22-category-theory...
freyrs3 13y ago
Are they needed? No. Are they useful abstractions? Yes. Like most abstractions in Haskell the theory is always optional.
nbouscal 13y ago
Strictly speaking very little is needed. You can write everything in assembly if you'd like. Helpful, though? There's absolutely no question. Type classes like those you mentioned make programs more concise, more understandable* , and more general. All of those are good things. * Specifically, understandable to people who know the language and concepts. Trying to be understandable to everyone is a terrible idea. For example, Cucumber.
dllthomas 13y ago
I regularly miss Monad as an abstraction in my C code and Functor in my C#. They're just plain helpful, FP or not. Needed? Probably not, though a case could be made that monad is sufficiently helpful to deserve that title for dealing with sanely ordering IO in a lazy language.

rtfeldman 13y ago

> the people who designed Haskell decided they weren’t going to pretend they didn’t use math This is almost certainly the decision that has kept the most people from successfully learning Haskell. If you write "Appendable", many programmers go "oh, okay, got it." If you write "Monoid", many programmers go "yeeeah, I don't know if I have time to learn all this." This is either a perfectly acceptable cost of avoiding redefining the wheel, or a cautionary tale for future language developers, depending on your perspective.

anaphor 13y ago
It's not really Appendable though, because e.g. you can write a Monoid instance for various number-y things like Sum and Product.
- srl 13y ago
  And you could write an Appendable instance for them as well, it would just fly in the face of what the word "append" means to most people. (Nitpick, of course.)
  - dllthomas 13y ago
    Sure, but is that more understandable than using "monoid"?
    - chilldream 13y ago
      Don't know enough to know that the current name is optimal, but at least "Monoid" correctly says to the initiated "you don't understand this yet." "Appendable" lies to you and says "you understand this" even if you don't.
      - dllthomas 13y ago
        "Monoid" also has the advantage of being very searchable. First result on Google (from a private browser window) is the Wikipedia page with the snippet "In abstract algebra, a branch of mathematics, a monoid is an algebraic structure with a single associative binary operation and an identity element". DDG gives similar results, though the Doctor Who aliens are higher up...

lmm 13y ago

You need the words to be able to use Haskell. There are too many of them to learn otherwise. I have a similar experience with scalaz, where I tend to only spot useful things in the library after I've reimplemented them, because they don't have names that let me find them based on what they do. (Possibly the only benefit of a previous company that wouldn't let me use scalaz was that, in reimplementing it myself, I got to give the typeclasses sensible names like "CanFlatMap")

jfarmer 13y ago

The problem with being a programmer and learning category theory is two-fold. First, category theory is very abstract. Indeed, mathematicians often jokingly refer to category theory as "abstract nonsense." The story goes that Norman Steenrod, one of the creators of category theory, coined this term himself. So, category theory can be abstract even for mathematicians. Second, the "stuff" that category theory was built to abstract is highly mathematical and foreign to virtually every programmer who doesn't have a math background. What's worse, the bits of category theory that Haskell uses most frequently are typically not the bits of category theory that mathematicians use most frequently. When you put these together, it's very hard to connect the dots between "category theory", "category theory as Haskell uses it," and "Haskell as a typical Haskell programmer uses it." To build up to the bits of category theory that Haskell uses requires understanding things like categories, morphisms, functors, adjoint functors, natural transformations, adjunctions, and commutative diagrams, to name seven. Trying to understand these without understanding their (inherently mathematical) motivations would be a tiny nightmare — they'd feel like a bunch of disjoint facts and diagrams that are supposed to mean who-knows-what. And even if you get there, the categorial nature of monads in Haskell is not exactly apparent on the surface. Haskell exposes more programmer-friendly interfaces like "bind" that take some effort to translate into the language of category theory. A major motivator in the development of category theory, for example, was as a tool to explore the relationship between topological spaces and groups, a field of mathematics called algebraic topology (http://en.wikipedia.org/wiki/Algebraic_topology http://en.wikipedia.org/wiki/Algebraic_topology).

Fasebook 13y ago
What a ridiculous assertion. Category Theory and Chomsky Hierarchy are two easy to understand and key theories of Computer Science. If you don't have any understanding of these, you're not a professional programmer. Maybe it's "even abstract for mathematicians" should be "too abstract for detail oriented math nerds, but pretty easy to comprehend at a basic level"
- jfarmer 13y ago
  I'm not sure what the Chomsky Hierarchy has to do with what we're talking about, but re: category theory, there's a difference between "understanding" and "familiarity." I agree that the definition of a category is not a hard thing to learn. However, can you give me, say, three non-trivial examples of categories you'd expect a "professional programmer" to know? How about three non-trivial examples of functors? If understanding category theory is a pre-requisite for being a professional programmer then 95% of the people I know who get paid to program aren't "professional programmers. You're just being silly. Or trolling. Probably trolling.

guard-of-terra 13y ago

With such a great number of people around me dabbling in Category Theory, I'm not sure it's worthwhile anyway. I don't like crowded areas. Maybe learn something useful but less hot - cryptography perhaps?

KirinDave 13y ago
Are you too cool for category theory? Fashion is a terrible reason to learn math, or to decide against learning it. Don't be a hipster.

badman_ting 13y ago

Makes sense if your goal is to use some particular language (in this case Haskell). But a lot of us don't necessarily need yet another programming language, whereas adding to our theoretical knowledge can be beneficial no matter what environment we're programming in.

saosebastiao 13y ago

I call mega-exponential-factorial-to-the-n-bullshit. I tried doing exactly that. You can't learn Haskell beyond superficial hello world apps without learning what a monad or functor are, because there aren't any substantial teaching materials that don't force you to understand it in order to continue learning, and all the common libraries require you to know how to use them because they are undocumented and have no examples. Can you use Haskell without understanding how those things work? Sure...if by "use" you mean you are limited to copied and pasted code snippets without an ability to understand what your code is doing, with the slightest change causing unintelligible compile errors.

nilkn 13y ago
My impression of the article was not that you don't need to know what monads and functors are, but rather that you don't need to understand them on the level of category theory. I think that's a true statement, if your interest is in simply writing software in Haskell and not in breaking new ground in the Haskell community (like writing the lens library itself).
nbouscal 13y ago
You have to learn what Monad and Functor are, but you do not by any means need to learn what a monad is, or what a functor is. To put it another way, you need to learn the Haskell type classes that have those names, but you do not need to learn the category theoretical constructs from which those names were taken. I believe this was the entire point of the article. The Haskell type classes are actually not too hard to learn at all, if you give it a bit of effort.
tene 13y ago
There's a significant difference between a wide understanding of category theory in general and understanding what a monad or a functor is used for in haskell. They're just type classes, nothing special. There's not all that much more to know about them besides their definition. I rather disagree that they are undocumented and have no examples. Section 6.3.6 in the haskell report 2010 defines the type class and provides examples: http://www.haskell.org/onlinereport/haskell2010/haskellch6.html#x13-1330006.3.6 http://www.haskell.org/onlinereport/haskell2010/haskellch6.h... See also, the typeclassopedia, which walks through a simple definition, many examples, and discusses general intuition: http://www.haskell.org/haskellwiki/Typeclassopedia#Monad http://www.haskell.org/haskellwiki/Typeclassopedia#Monad Perhaps I've misunderstood you, and maybe you mean that common libraries are undocumented and have no examples? That certainly hasn't been my experience; most libraries I've run into have plenty of documentation for me. Can you give me some examples? Yes, I agree that trying to write haskell without being able to understand simple type classes would be very difficult and confusing, but I disagree with what I understand the implied point to be, perhaps you could clarify this for me? I understand you to be saying here that you expect to be able to proficiently use a language with negligible understanding of how data types work in the language, or the common data types defined in the standard library? That sounds like nonsense to me, so I suspect I'm confused here; can you be a bit more explicit in your criticisms here?

rschmitty 13y ago

Side note from this submission is that I did learned you can host html like github https://confluence.atlassian.com/display/BITBUCKET/Publishing+a+Website+on+Bitbucket https://confluence.atlassian.com/display/BITBUCKET/Publishin... Nifty!

tikhonj 13y ago

A bit of a link-baity title. It's not that you shouldn't learn category theory, it's that you don't have to. Even if you want to program in Haskell. But is it worth learning on its own? Probably. At least the basics are. You'll get more insight into the design of languages like Haskell and ML and acquire a bunch of new abstractions which have a very good "power-to-weight" ration: that is, abstractions which are surprisingly general and expressive but also simple. The compromise, of course, is that these abstractions are really abstract--they do not admit good concrete explanations. At first, thinking about this sort of abstraction is difficult, but they become extremely powerful and convenient once you get used to them. Category theory also helps people design libraries. In a sense, category theory is focused on composition, which is obviously integral to writing good code. Additionally, some extremely useful constructs--like prisms from the lens library--were discovered largely thanks to category theory. Finally, category theory gives you a new perspective on programming. I find this very valuable because it gives me more than one way to think about whatever I'm working on. It's useful in the same way Curry-Howard is useful--in fact, there's a very natural extension of Curry-Howard to include categories with certain structure. So yeah: please don't feel you have to learn category theory, but consider learning it anyway.

joe_the_user 13y ago
But the alternative he proposes actually sounds more daunting than learning category theory: "In fact, try substituting Monad -> FuzzyWuzzy Functor -> Banana Category -> Cheerios" Sure, uh, all the other languages I've learned involved using opaque labels whose meaning I had to infer over time. No, that approach is for something like esthetic theory. All the languages I've learned used pretty concrete intuitive terms for their constructs, even the terms weren't really accurate. Having to manipulate a construct without the slightest hint to qualities sounds just maddening. Learning a programming language is hard enough that I think the learner needs terms that suggest they're dealing with something concrete even if they're not.
- axman6 13y ago
  Then try Monad -> Sequenced Functor -> Mapable Category -> ... I don't know, I don't use it much (not that it doesn't have a nice understandable alternative name, I just don't know it) Monad and Functor are really quite simple classes to understand, and Tony Morris' 20 intermediate exercises listed in the article helped me greatly when trying to understand the concepts. I've been a haskell programmer for 6 years, and feel I know about zero cetrgory theory. It's never seemed to hurt me (except when Edward Kmett pipes up in IRC and I don't understand a word after that =)

ekidd 13y ago

This is a nice, short article which basically says, "You don't actually need to go learn a bunch of category theory if you want to learn Haskell, so please don't stress about it." Despite the title, it's not any kind of general argument that no programmer should learn category theory. Category theory is a strange branch of math—it's almost entirely definitions, with only a handful of interesting theorems. As far as I've been able to understand, category theory is a very abstract analogy between very different branches of math: abstract algebra, topology, mathematical logic and (here's the interesting part) the lambda calculus, via Cartesian closed categories. This analogy has interesting payoffs, especially for programming language designers and people trying to do seriously weird stuff. For example, let's imagine you have a value of type A, a function from type A to type B, and another function from B to C. But if you squint at these types right, it's the same as a logical system where A is given, A implies B, and B implies C. Now, it turns out we have automated theorem proving software that can take statements like this and figure out how to get from A to C (even in much more complicated situations). And it turns out the analogy between types and logic is sufficiently strong that you can actually use a theorem prover to write certain kinds of programs without any human intervention, given nothing but the type signatures of your functions. And this is not the only clever analogy lurking here: My favorite is the way that probability distributions can be mapped onto the lambda calculus. So, no, you don't need to know all this math to write Haskell programs. (Although some library authors are a little nuts, generally in a good way.) And yes, category theory is a weird branch of scarily-abstract math without many theorems, and Haskell only uses certain corners of category theory. Still, there are times when category theory will allow you to see how far-flung branches of math can be mapped tidily onto the lambda calculus. And that should be of interest to Lisp developers, at least.