I agree to an extent, but I think it's a minority opinion. I had a similar point to make about monoids, and would rather see them called "addables" or something similar. Yes, yes, I know, they're not just about adding things... but a great majority of times, `mappend` is used as an adding operation, or something similar (union of sets, concatenating strings, etc). But I didn't receive much support for this view, because "look at the definition of a monoid in abstract algebra! It is a monoid!"
It's this kind of thing that makes Haskell so cool, but also makes it so unlikely that it will ever see real widespread adoption. Haskell is a language based heavily on mathematical theory. There's more of a focus on expressing mathematical concepts and hewing to theoretical correctness than on being practical. Why are there no (real) exceptions in Haskell? Because you can do it with monads. Why aren't there member variables on objects? Because you can do it with functions (or better yet, lenses! a shiny new abstraction to learn!). Why is there no stack trace when a runtime error occurs? This one I don't have a good answer to, but I think it has to do with laziness, which has its roots in theory as well.
I love Haskell and have written several large projects in it. I write it almost every day, currently in the middle of a project with ~1,500 lines of code written over the last month or so. But a lot of it feels like bending over backwards to allow features that would be completely basic in other languages, because of the thing I was talking about above: the starting point is the theory, and the practical comes after. The names of the types are just the tip of the iceberg on this one. There are many great and practical libraries for Haskell (some of which this post's author has written), and many are incredibly powerful, expressive and performant, so it's wrong to say that Haskell isn't "for the real world". But it's really a whole different philosophy than 90% of other languages.
All that said I'm not sure I can come up with a better name for Monad. Context? Pipe? Container? Nothing really springs to mind. It's sort of its own ball of wax.
I think Haskell as a community favors more learning over having edges to abstractions. You could call Monoids "Addables" and it would make intuitive sense more quickly, but it would (a) face edge cases later (multiplication is a monoid, as is "take the leftmost argument") and (b) not link to a larger literature of abstract algebra.
That turns a lot of people off, as you mention, since they want the names of things in their language to provide immediate (partial) intuition as to what's going on.
The upshot is that reading Haskell expects more background literature in abstract algebra (or at least a willingness to read the docs for a while to learn a new vocabulary) but suffers fewer intuition breakdowns.
I think that's a general theme of the style of Haskell programming—suffer few intuition breakdowns. It's reinforced by purity, equational reasoning, sophisticated types, top-level annotation style, some parts of laziness, etc. Altogether these pieces fit together to form something unique and interesting.
So that tradeoff of immediate understandability is painful. The community is battling it by (increasingly) building more and more public documentation. Without that tradeoff Haskell wouldn't be as unique and specialized, though.
Yeah, I agree. Haskell has an almost unmatched capacity for abstraction and high-level thinking. This can be a double-edged sword, but it has made Haskell pretty much in a class of its own, and a very special language.
I'm not sure how helpful intuitive names are in practice, especially when the real concept has nuances that it doesn't capture. What do you get by renaming Monoid "Addable" that you don't get from the first line of a tutorial saying "Monoids are things that can be added"? Then, once you've got the intuition, it's much easier to absorb the line further down which says "oh, but they also need to be associative and have a zero element" because you already have a separate name to file these new properties under. It also provides a precise name for further discussion.
Also, on the topic of names for Monads, the key difficulty there is that there are at least two distinct ways of thinking about them which can be applied in different cases. Some Monads are best described by their join (List, Maybe etc.) and some are best described by their bind (IO, State etc.).
It's this kind of thing that makes Haskell so cool, but also makes it so unlikely that it will ever see real widespread adoption. Haskell is a language based heavily on mathematical theory. There's more of a focus on expressing mathematical concepts and hewing to theoretical correctness than on being practical. Why are there no (real) exceptions in Haskell? Because you can do it with monads. Why aren't there member variables on objects? Because you can do it with functions (or better yet, lenses! a shiny new abstraction to learn!). Why is there no stack trace when a runtime error occurs? This one I don't have a good answer to, but I think it has to do with laziness, which has its roots in theory as well.
I love Haskell and have written several large projects in it. I write it almost every day, currently in the middle of a project with ~1,500 lines of code written over the last month or so. But a lot of it feels like bending over backwards to allow features that would be completely basic in other languages, because of the thing I was talking about above: the starting point is the theory, and the practical comes after. The names of the types are just the tip of the iceberg on this one. There are many great and practical libraries for Haskell (some of which this post's author has written), and many are incredibly powerful, expressive and performant, so it's wrong to say that Haskell isn't "for the real world". But it's really a whole different philosophy than 90% of other languages.
All that said I'm not sure I can come up with a better name for Monad. Context? Pipe? Container? Nothing really springs to mind. It's sort of its own ball of wax.