Haskell Names Considered Helpful

I've been working on a SQL parser and pretty-printer in Haskell to help me in my duties as a DBA. After using Parsec, I will never go back to lex and yacc if I can help it. Like most Haskell newbies, I had a hard time with monads at first. I also struggled with the type system, but now I find that it actually makes things easier, especially refactoring.

There's a very active thread going on at fa.haskell about a blog posting linked to in the header. It's a very good article, especially the bit about data being code. But I have to take exception to this part:

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.

My feeling on this is that using a name like "Appendable" instead of "Monoid" because Appendable is more intuitive is exactly the wrong thing to do. If you see the name "Appendable" for the first time, you think you know what it is. Unfortunately, in this case, the definition you would assume the name has is incomplete at best. However, you don't know that because the name is intuitive, so you don't look it up. Not yet. But you may have to later when you find out that it doesn't exactly do what you want, or you may never have to, which is worse because you won't find out what else it can do.

This is actually an example of a larger trend in computing: making things intuitive and easy to understand for beginners is given a higher priority than developing in-depth knowledge and making tools that are fast and efficient to use for experts. And that's O.K. for the mass market. If you're just writing CRUD screens in VB, C# or Java, then just knowing enough to get by is fine, but you wouldn't be interested in Haskell anyway.