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.