What's wrong with the names? I see this complaint everywhere but not a single person has yet managed to explain to me what's wrong with them. Is it because they're from math? Perhaps we should rename them after dog breeds or something.
Nothing is wrong with them. A lot of people aren't used the level of abstraction that Haskell uses, so they look at a specific instance of the structure (often the List type) and think of a name that fits that instance ignoring the more general class. You end up with names like Appendable ( Monoid ) or FlatMappable ( Monad ) both of which give horrible intuition for the general case.
I think the abstract algebra names are great because they describe the general case precisely without any preconceptions carried along with them.
What's wrong with the names is that they don't communicate very well to the 95%+ of programmers who aren't in the FP/Haskell world. That's most of the people who are going to try to use it on C++.
I mean, some concepts are clearly not able to be explained to the layman; you need some background. But do people really need to learn abstract algebra to be able to get their heads around this stuff? Are there no better terms that communicate to more people?
And, given that that's the problem, clearly dog breeds are not the answer either.
What's wrong with the names is that they don't communicate very well to the 95%+ of programmers who aren't in the FP/Haskell world. That's most of the people who are going to try to use it on C++.
I'm not a C++ programmer; I don't know what half the names are from the GoF book. Does that make them bad names? No! Since when should a word have to carry around its own definition so that people who've never seen it before automatically know what it means?
I mean, some concepts are clearly not able to be explained to the layman; you need some background. But do people really need to learn abstract algebra to be able to get their heads around this stuff? Are there no better terms that communicate to more people?
Concepts like Functor and Monoid and Monad are extremely simple. You don't need to go back to school to learn them. You only run into trouble if you expect them to be explainable by analogy to a more concrete notion.
And, given that that's the problem, clearly dog breeds are not the answer either.
It was a sarcastic remark but it highlights an important point I want to make. Assuming you knew nothing at all about dogs; if you were given a list of dog breeds and a stack of photos of dogs, would you be able to match the breed names to the photos? No, probably not. That doesn't mean their names are bad; you simply lack the experience to figure it out.
I think the point is that if you did get into C++ you'd get a pretty good grasp of the keywords and other common identifiers without even having to look them up. They are mostly all designed to appeal to intuition.
>Concepts like Functor and Monoid and Monad are extremely simple. You don't need to go back to school to learn them.
The issue here is not at all how complicated the concepts are. The issue is how common and/or descriptive the name for them is. "Monoid", to someone who hasn't studied abstract algebra, is neither. Something like "Appendable" might be more appropriate for C++.
> "Monoid", to someone who hasn't studied abstract algebra...
Oh come on, man! I can't believe this ridiculous discussion. I'm not lashing out at you, don't get me wrong, but seriously, you think you need to study abstract algebra to understand what a monoid is? Um, I remember one of the first things mentioned in the, literally, first lecture in undergraduate course on calculus was a monoid, among other algebraic structures. Granted, it was theoretical physics, but still, I doubt any respectable university teaching CS would fail to give students at least some familiarity with basic algebraic structures. But you don't even need a university education to grasp this, seriously, stop being afraid of precise terms, there's nothing scary behind them.
EDIT: And to actually address your point :), "intuitive" can only go so far. Sometimes there is simply no intuitive term that can do justice to the concept at hand. As Feynman once said: "I'm not going to lie to you, I'm not going to tell you it's like a ball bearing on a spring because it isn't." Especially in programming I'm not convinced that intuitiveness of a mere label for something is a valuable goal. You can't program on intuition, at some point you just have to learn how the thing really works.
> you think you need to study abstract algebra to understand what a monoid is?
No no no. My whole point is that while the concept is not complicated, that particular term ("monoid") simply isn't common.
I agree with your edit section though. And I don't necessarily think C++ shouldn't adopt the term 'monoid' due to its relative obscurity (especially if no better term can be found); I just think it's got some figurative points against it for that reason.
> Something like "Appendable" might be more appropriate for C++.
So I can append False to True to get False (Boolean monoid under &&) or append 8 to 9 to get 72 (integer monoid under multiplication)? There's also a monoid instances for any single-argument function into a monoidal type, where (f <> g) x = f x <> g x; I don't know what to call that but it's definitely not appending.
Append is a name that works in a few cases but horribly breaks down in the general case.
Math has a tradition of one-letter names. I mean who in their right mind would name anything with rich semantics as just a, b, c, or x, y, z, or B, C, D... Oh wait...
