I'm not going to claim to have a better name at this moment.
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++.
Both "object" and "method" are common words with very obvious parallels between the programming language concepts and similar real-world concepts that are familiar to basically everyone. That's what makes them good terminology.
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.
'"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.
If you limit yourself to concepts you can express by relating them to the physical-world objects and human actions then you lack the language to express abstract concepts entirely. The words used by mathematicians are chosen to describe these structures have no real-world connotations because the ideas, in their-full generality, have no representation in our every-day experience. There's no way you'll ever be able to describe any reasonably complex structure from abstract algebra by concatenating a bunch of household adjectives, it doesn't capture the full-generality or convey any more information.
So what kind of object is a multiplication, or an addition? Monoid has "no real good real-world parallel" because it is not a real-world concept. -- "It has no related or relevant meaning outside of very, very specific contexts" -- Well, that's the very nature of these abstractions; they apply to many many contexts, when working with data.
You are being too optimistic about object and method. (They look familiar because of long exposure to OOP.)
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...).
'"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.'
Also, this objection would seem to apply equally well to functions and variables as monoids.
I wouldn't say so. "Function" is a pretty common term used to refer to somebody doing some specific task. There's an obvious correlation between an employee tasked with a carrying out a specific role or action, and a chunk of source code that does something specific.
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".
The everyday meanings of these words are misleading when applied to the context of a particular programming language. Variables in one language are not at all related to variables in another. Mathematical variables, for example, do not change at all. Similar differences exist for functions and objects. These highly-overloaded terms are a constant source of confusion for people trying to learn different programming languages.
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.
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++.