5 ms·
The problem with being a programmer and learning category theory is two-fold. First, category theory is very abstract. Indeed, mathematicians often jokingly r
by 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 agoWhat 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 agoI'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.
- deleted 13y ago[deleted]
- haberman 13y agoI don't think the Chomsky hierarchy is very useful for Computer Science, except the distinction between regular and context-free languages (which is extremely useful). "Context-sentitive language" in the Chomsky hierarchy is not the same as what a programmer means when they say a language is context-sensitive. In programming languages, "context-sensitive" nearly always refers to semantic context-sensitivity (for example, the set of symbols that are defined at this point and their types), not the syntactic context-sensitivity described by the Chomsky hierarchy. For example, none of the context-sensitivity described on this page has anything to do with Chomsky context-sensitivity: http://eli.thegreenplace.net/2007/11/24/the-context-sensitivity-of-cs-grammar/ http://eli.thegreenplace.net/2007/11/24/the-context-sensitiv... I can't think of a single case where Chomsky type-0 or type-1 grammars are relevant to any practical concept in computer science. And due to overloading of the term "context-sensitive" learning about the Chomsky hierarchy can be actively misleading unless you are aware of this distinction.
- ggchappell 13y ago> I can't think of a single case where Chomsky type-0 or type-1 grammars are relevant to any practical concept in computer science. Not the grammars per se, but the notion that there are things computer programs cannot do -- and that we have a good handle on what these things are -- is an important one. As for Chomsky's Type 1, I've seen no evidence that the concept of a context-sensitive language has been of practical use to anyone, ever. It looks like an idea that turned out to be a dead end. EDIT. To clarify: Certainly there are CSLs that have been of practical use. But the fact that a certain language is or is not a CSL, does not seem to be something worth knowing.
- tel 13y agoWhile the origin of category theory can indeed be described that way, and while the formalisms are weighty to anyone not familiar with mathematics style proofs, the notions should not be too hard to someone with good FP background. Especially typed FP. The real problem is more a question of why should someone learn it to begin with. Category theory will inform you that pairs are also called products and they're somehow the best kind of product-like thing. Big deal? I don't have a really great answer to this question yet besides CT is like taking an X-Ray to computer languages and really asking "what does this mean?" Getting to see how a CCC develops into a programming language with sensible notions of computation, dynamics, simplicity is incredible and will end debate about language semantics. That and dualization. Once that's in your head you don't want to go back.
- drblast 13y agoI always feel like I'm at least seven or eight layers removed from anything I can relate to when I read about category theory. I'll think, "Hey, let me check this out on Wikipedia..." and I'm six linked articles deep trying to understand the first paragraph of the original article, and I'm no closer to anything concrete. It's obvious at that point that the "top-down" approach is the wrong way to go and that really the only way to develop an understand this is to take a class, or buy a book that may or may not be more tractable than Wikipedia. At that point, I'll consider that there are many other languages that are supposedly esoteric that I've never had a problem grasping, and that I know of few advantages that Haskell offers over, say, F#, for doing things I need to do. And even though I've written some parsers in Haskell and it was a generally nice experience, I just don't have time to learn category theory from the ground up. I also realize I really, really need to understand how my tools work from cradle to grave or I'm deeply unsatisfied. At that point I abandon Haskell as a curiosity and go on with the rest of my life.
- dllthomas 13y agoLike the article here states, though, you don't need to learn category theory to learn Haskell. Most math is useful in driving intuition and insight, and Category Theory is no different in that respect, but learning Haskell (in particular enough to use it and write normal applications and libraries, not necessarily create the neatest cutting-edge type-trickery libraries - some of which are amazing) requires much more of a concrete "here's how you use these things" than any knowledge of Category Theory.
- chongli 13y agoThe real problem, if you ask me, is that we've all gone through elementary and secondary school working with all kinds of mathematical objects without learning their proper names. Every kid ought to be told what semigroups, monoids, groups and rings are shortly after learning addition and multiplication.
- j2kun 13y agoIf you're interested in more of a bottom-up approach, I have a series of articles on my blog explaining category theory with the programmer's perspective in mind (though I do assume you know a little bit of higher maths; sets and functions, mostly). See the section titled "Computational Category Theory" on this page: http://jeremykun.com/main-content/ http://jeremykun.com/main-content/ I've let the series sort of fall to the wayside recently as I focused on other content, but there's enough to get you up to a categorical understanding of map, fold, and filter (and a mathematical justification for why fold is the "most" universal one of the three)