On keeping category theory and abstract algebra alive in Haskell

The Haskell community it abuzz over this article by Brian Hurt. His article is an interesting one, because it documents some insightful first-impressions about Haskell.

Undoubtedly, the part that has gotten the most attention is his suggestion that the Haskell community stop using mathematical names (as a default) for our common idioms. To quote:

One thing that does annoy me about Haskell- naming. Say you’ve noticed a common pattern, a lot of data structures are similar to the difference list I described above, in that they have an empty state and the ability to append things onto the end. Now, for various reasons, you want to give this pattern a name using on Haskell’s tools for expressing common idioms as general patterns (type classes, in this case). What name do you give it? I’d be inclined to call it something like “Appendable”. But no, Haskell calls this pattern a “Monoid”. Yep, that’s all a monoid is- something with an empty state and the ability to append things to the end. Well, it’s a little more general than that, but not much. Simon Peyton Jones once commented that the biggest mistake Haskell made was to call them “monads” instead of “warm, fluffy things”. Well, Haskell is exacerbating that mistake. Haskell developers, stop letting the category theorists name things. Please. I beg of you.

I’m a mathematician, so perhaps my opinion on this should be taken with a grain of salt. But to be fair, I came to Haskell years before I had taken any category theory, and back before my abstract algebra was where it is today.

It’s been said elsewhere, but I think it bears repeating: we basically have two choices on this issue.

  1. We use less technical names, so that we don’t scare off people who are scared of technical names.
  2. We call it what it is, with the added benefit that people who are familiar with these ideas can come to the language and apply some existing intuition.

Each option picks a preferred audience, where the audience for (2) is undoubtedly in the minority. But is that necessarily a bad thing?

Haskell is a Great Language Experiment. Originating in academia, it has been built out of a vast collection of wildly strange ideas, more or less just to see how well these ideas would work out. We’re watching that experiment unfold today.

Some parts of the experiment are obvious, such as using monads to bring side effects into the type system. Others are less obvious, such as suggesting that we should think about our software in terms of category theory and abstract algebra.

So thus I suggest the following perspective: just as we have become convinced that monads are a better way of modeling side effects, so too may we be convinced that these branches of math provided a good way of thinking about programs. If we do become convinced of this, then it behooves us to stick with this nomenclature and rethink our approach to training programmers. After all, it might be the case that an army of programmers who thinks in these terms will produce better results than army that doesn’t. If so, we should adopt this practice!

Of course, this has the obvious disadvantage of disenfranchising those programmers who won’t or cannot think of their problems in these terms. That’s fine; Haskell doesn’t need to be for everybody, just as not everybody needs to love Java, or Python, or Assembly, or Ada, or whatever.

What’s best is to attract people to Haskell who can like it for what it is, because once we decide we need to change Haskell to suit the needs of the people who don’t like it, then we’re no longer talking about Haskell, but rather some strange derivative language. In principle there’s nothing wrong with that; I’m not married to Haskell — just to the ideas that make it great. After all, at some point a language will come along that takes Haskell’s ideas as a foundation and expands on them in some nontrivial way. When that happens, I’ll convert to the new language, just as I converted to Haskell. It’s not clear to me, though, that renaming everything will bring about this sort of revolution.

Besides, let’s be honest: is it really the names that are tripping people up, or is this just more “monads are like burritos?” Sure, you can look at a monoid and say “aha! if only someone had called this thing appendable, I would have understood it from the beginning.” But is that really true, or is it just an excuse for having a tough time grappling with a genuinely new idea?

Sure, I grant that it’s not very helpful to try to teach monads to people by starting with examples of adjoint functors, talking about the semantics of join, etc. It’s much more helpful to start by explaining how the idea gets used, and then get into the abstract business of it all (for the people who are so inclined). But this is a problem in how we explain the ideas, not in what we call them.

Indeed, let us not forget that this abstract business does have some advantages. For instance, if one invests the (admittedly serious amount of) time to read a bit about monads and categories, then one finds that it should be obvious that linked lists are monads, since linked lists are really just free monoids, and the free monoid is adjoint to the forgetful functor, so that the composition gives a monad. Technical? Absolutely. But if you can get past that, then there’s a lot of insight one can gain into the underlying nature of what’s going on.

These algebraic and category theoretic foundations have inspired a lot of great ideas in the Haskell community. Renaming everything obfuscates the ideas, and will slow down future developments and unifications. In my experience (and I suspect the experience of many others), the “call it what it is” approach has made it much easier to see the big picture in my programs. Are we really ready to give up the conventions and way of thinking that got us where we are?

Leave a comment


  1. After thinking about it a bit more, I think my position could be summarized like so:

    we expect programmers to be comfortable with terms like “register,” “pointer,” “polymorphism,” etc. Not every programmer needs to know these terms to be good at what they do, but knowing how to use these words makes it easier to study one’s craft and become a better programmer.

    I guess I don’t see the difference between asking our freshmen to learn these terms and asking them to learn words like “monoid.”

    In both cases, you don’t really need to know what the words mean to be able to use the ideas; they are just names, after all. But by using these standard terms, it’s much easier to dig deeper and improve your craft.

    Freshmen get put off by words like “pointer,” but they get over it. I think the same thing can be the case for the Haskell nomenclature.

  2. K9

     /  18 January, 2009

    Programmers do need to understand the theory behind the primary tool of their craft, namely the programming language.
    I have never met a programmer who did not understand what’s going on under the hood that was more than mediocre, at the very best.
    I think programmers should be required to understand the modern concepts by which their tools were built.
    First, Thinking it’s too damn complicated for them is insulting and shows of no real understanding of what good programming and software engineering are all about.
    Second, these concepts broadens one’s mind. Thinking in Monads gives one a whole new perspective of the kind of problems it aims at solving.
    The I-can-grasp-the-concept-of-a-for-loop-therefore-I-am-a-programmer should be (and thankfully are) over. These days generated armies of amateurs writing bad code in huge quantities. Programming and software engineering are complex craftsmanship and should be treated as such.

  3. As a mathematician by training (mostly) who never got as far as category theory and its friends, those aspects of Haskell are both frightening and fascinating to me.

    One day, I intend to actually understand it all, but until then I am happy to “just” program in Haskell, without any particular worries.

    Perhaps my Haskell is very superficial as a result, but it doesn’t stop me being able to make things happen.

    I think people can get too caught up in all the theoretical underpinnings. Yes, they can provide a more intimate understanding, but they are by no means necessary.

    I enjoy programming in Haskell, and that’s what matters to me.

  4. I really like this a lot; I think it gets to the heart of the issue that this discussion grew from:

    Colin Ross:

    I think people can get too caught up in all the theoretical underpinnings. Yes, they can provide a more intimate understanding, but they are by no means necessary.

    I enjoy programming in Haskell, and that’s what matters to me.

  5. dainanaki

     /  20 January, 2009

    I know this is really off-topic, but when are we going to get to see the code for Kinetic? I’ve been messing around with a little OS-in-progress, and I’d really like to try implementing one myself. I was hoping reading some of your code would provide a bit more insight!

  6. @dainanaki

    I haven’t touched Kinetic in 2 years :)

    I’ll post the code this weekend, when I’ll have a chance to make sure I can explain the build process, and write up a bit more explaining how the code I have is [insert several disclaimers here].

  7. sooo fake, Pierre Kiyuna

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: