5 ms·

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

by 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 =)
  - joe_the_user 13y ago
    Yes, that works much better. But that isn't what the article said. I'm a c++ programmer who consumes the occasional Haskell articles on hn. By dint of complaining and hearing sensible explanations, I feel like I'm "getting it". But I don't think that takes from the notable phenomena of opaquely ridiculous explanations of Haskell ideas that seem to pop-up regularly. http://www.chrisstucchio.com/blog/2013/write_some_fucking_code.html http://www.chrisstucchio.com/blog/2013/write_some_fucking_co... Edit: I kind of feel like there's this phenomena where someone is "real math guy" and so they'd rather people to wholly ignore the structures the language is built on, call functors Poptarts etc, rather than giving a simplified explanation which would leave them open to other real math guys complaining the explanation wasn't exact/cool/powerful enough.
  - ekidd 13y ago
    For Monad, try "Flattenable". A monad is any type which: 1. Supports map. 2. Can be instantiated given a single value. 3. Can be "flattened" when nested two layers deep. For example, an ordered list is a monad, because: 1. You can map a function over a list. 2. Given a value x, you can construct the list [x]. 3. Given a list like [[1,3], [2], [], [4,5]], you can flatten it to be [1,3,2,4,5]. There are a couple of other technical constraints, mostly related to what happens when you (for example) take a list, stick into another list using rule (2), and flatten it using rule (3), in which case you're supposed to get back the original list. That sort of thing. Monads are useful, and they appear everywhere—quite a lot of generic types support "map" and "flatten". Haskell obscures this simple structure in two unfortunate ways: (a) the first monad that everybody sees is IO, which is a freakish outlier, and (b) Haskell uses an equivalent formation of monads based on a function "bind", which is essentially a map (to a doubly nested type) followed by a flatten. Another way to look at monads is as "generalized list comprehensions" where "list" can be replaced with hundreds of different clever things. It's a clever little pattern that turns up everywhere, and when it does turn up, it tends to be a sweet spot in the design space. A good recent example would be the Promises/A+ spec for JavaScript, which is basically Haskell's Error monad.
jfoutz 13y ago
I like the abstractions that _do not leak_.

by tikhonj 13y ago

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 =)
- joe_the_user 13y ago
  Yes, that works much better. But that isn't what the article said. I'm a c++ programmer who consumes the occasional Haskell articles on hn. By dint of complaining and hearing sensible explanations, I feel like I'm "getting it". But I don't think that takes from the notable phenomena of opaquely ridiculous explanations of Haskell ideas that seem to pop-up regularly. http://www.chrisstucchio.com/blog/2013/write_some_fucking_code.html http://www.chrisstucchio.com/blog/2013/write_some_fucking_co... Edit: I kind of feel like there's this phenomena where someone is "real math guy" and so they'd rather people to wholly ignore the structures the language is built on, call functors Poptarts etc, rather than giving a simplified explanation which would leave them open to other real math guys complaining the explanation wasn't exact/cool/powerful enough.
- ekidd 13y ago
  For Monad, try "Flattenable". A monad is any type which: 1. Supports map. 2. Can be instantiated given a single value. 3. Can be "flattened" when nested two layers deep. For example, an ordered list is a monad, because: 1. You can map a function over a list. 2. Given a value x, you can construct the list [x]. 3. Given a list like [[1,3], [2], [], [4,5]], you can flatten it to be [1,3,2,4,5]. There are a couple of other technical constraints, mostly related to what happens when you (for example) take a list, stick into another list using rule (2), and flatten it using rule (3), in which case you're supposed to get back the original list. That sort of thing. Monads are useful, and they appear everywhere—quite a lot of generic types support "map" and "flatten". Haskell obscures this simple structure in two unfortunate ways: (a) the first monad that everybody sees is IO, which is a freakish outlier, and (b) Haskell uses an equivalent formation of monads based on a function "bind", which is essentially a map (to a doubly nested type) followed by a flatten. Another way to look at monads is as "generalized list comprehensions" where "list" can be replaced with hundreds of different clever things. It's a clever little pattern that turns up everywhere, and when it does turn up, it tends to be a sweet spot in the design space. A good recent example would be the Promises/A+ spec for JavaScript, which is basically Haskell's Error monad.

jfoutz 13y ago

I like the abstractions that _do not leak_.