The most useful name is probably somewhere in the middle. It may not necessarily consist of everyday words, but it probably relates very obviously and clearly to the C++ functionality.
"Monoid" is a very detached term. It doesn't obviously relate to the C++ construct or concept the way that terms like "typedef", "template", "stream" and so on do for other constructs/concepts.
Monoid is NOT a detached term it says I have a type with an identity element, and an associative binary operator, and that that (id `op` elem) always is elem. Try to tell me that i complicated in the slightest. I can most definitely not give you a single line description of templates, or most C++ features. Abstraction makes things more general (i.e less specific) meaning it is easier to describe, reason about, and discuss because I can only talk about things that hold universally.
If you doubt me let's show some things that form a Monoid right now, and how easy it is to define.
1) Strings - identity element = "" - associative operator = +
2) Lists - identity element = list<A>() //empty list - associative operator = concat
and we can go on and on finding instances of Monoids simply from a one line description.
Just for the record, I'd like to state that I couldn't make heads or tails of this explanation. 'Identity element', when thinking of C++, just makes me think of a hash function or something.
Looking at the examples, it's sort of clearer— a monoid is a type that can hold a value that's empty (or zeroed, or whatever). But that doesn't change the fact that that explanation (and the term 'monoid') is so firmly rooted in math jargon that it's basically incomprehensible to someone used to thinking in C++.
It's firmly rooted in like 5th grade math. Every child in the US that takes basic algebra in school learns about identities and identity rules like "0+x=x" or "1*x=x" or in pseudocode as something like "(id `op` elem)=elem".
Possibly, C++ should adopt the name anyway, but it's by no means a commonly used or understood term by most users of C++. As has been mentioned, C++ is above all a language whose design is driven by pragmatism, so if another more common term can be found for the idea of a monoid you can bet it'll be preferred (even at the expense of some literary accuracy).
For most C++ terminology, you don't need to give a single-line description. The keyword or concept name alone generally embodies that information very well. To use your example, at a basic level a C++ "template" is quite similar to a form letter, stencil or other real-world "templates". It's a predefined mold that you inject your specific information/material into to get a final product with minimal effort.
There just isn't a direct relation back to the real world with a term like "monoid". You end up with people who are confused at best, or more likely they're thinking of some other word that sounds similar but is totally unrelated.
And that might even be a good thing. The stencil analogy for C++ templates gives you a warm fuzzy feeling, but doesn't actually help you program. Contrast: the one line definition of Monoids is all there is to them. That's all there is to know about Monoids.
Classic. Sometimes Haskell fans have useful things to say, and sometimes they're just using terminology to try to win an intellectual dick-size war. The tricky part is telling the two apart.
Imagine trying trying to describe a monoidal category or topoi in the OOP style, it's like trying to describe what a Fourier transform is to someone who insists on using roman numerals.
Or describing Latin declensions to someone who reads kanji. The key is that, if the audience admires Latin speakers, you can appear smart.
Such as?
"Monoid" is a very detached term. It doesn't obviously relate to the C++ construct or concept the way that terms like "typedef", "template", "stream" and so on do for other constructs/concepts.
Well of course! Monoid is far more general than those other concepts. It's also a far better name, being unambiguous. Those other names are reused all over the place in different contexts and their meanings subtly shift between their uses. Monoid is not so overloaded; once you learn it, you know what it means every time you encounter it.
However, I would like to think that there's somebody out there who could come up with a name that describes the concept sufficiently, while still using pragmatic C++-style terminology.
All I'm saying is that "monoid" is terminology of a style that's very different from basically all other C++ terminology. To many C++ programmers, even those with a background in mathematics, it's no better than gibberish.
At least the existing C++ keywords and terminology tend to be far more descriptive of what they're referring to, even if there is ambiguity in some cases. This is true even for the more abstract concepts in C++.
What does that mean? How is it any more detached than object or method?
An "object" is something specific that exists (implying it can likely also be created and destroyed), and can be distinguished from other objects. This applies equally well to a combination of a data structure and some related code as it does to a tennis ball, or to a car, or to a book.
A "method" is a systematic way of doing something. That "something" could be the operations described by some source code, or it could be tying a shoe, or even brushing one's teeth.
"Monoid" has no good real-world parallel. It has no related or relevant meaning outside of very, very specific contexts. That's what makes it "detached". It's off on its own, with an isolated and non-obvious meaning.
It's jargon, but it's jargon shared across a few fields, which makes it more worth learning. And while it lacks a "real-world parallel" it has a lot of simple examples. Lists over concatenation, integers over addition, positive integers over max, negative integers over min... It's interesting and informative to observe why integers over max (or min) is not a monoid but is a semigroup.
The Haskell people share your concerns. Simon Peyton Jones famously suggested "our biggest mistake [in designing Haskell was u]sing the scary term 'monad' rather than 'warm fuzzy thing'". (https://research.microsoft.com/en-us/um/people/simonpj/paper...).
Also, this objection would seem to apply equally well to functions and variables as monoids.
And the same holds true for "variable". It's a very common term for things that change their state of being, including stuff that isn't directly related to programming or mathematics. Stuff like the weather, somebody's mood, and so on.
"Monoid" just doesn't have any everyday meaning like those terms do, especially a meaning that so closely resembles the programming concept like in the case of "function" and "variable".
Monoid, on the other hand, has no such problem. If you look it up, its meaning in mathematics directly translates to its meaning in Haskell.
Yeah, they mean yet something else in statistical software.
Most people are inherently familiar with the concept of a "container", in the sense of something that holds other things, regardless of whether it's a physical container or a data structure.
"Iterator" might not be as clear as "container", but at least most people are familiar with the concept of doing something repeatedly, whether it's some physical action or executing some chunk of source code.
"Monoid" just isn't like that. It may be concrete when constrained to the context of mathematics or programming, but it's quite meaningless outside of those very specific contexts.
But that isn't really true. Addition and multiplication are both real-world examples of monoids that everyone is familiar with (obviously, these aren't physical things, but I don't see why that's relevant).