Comment by jroesch | Hacker News Reader

Comment by jroesch | Hacker News Reader

Parent Full thread

Not really I've had Java developers look me in the face and say that the nonsense names (very much like the one above) that Spring uses are somehow more readable than simple operators or abstract names.

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.

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.

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++.

> 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".

Every child certainly doesn't learn the term "monoid" though. The issue here isn't the concept; it's the terminology.

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).

I'm not sure that Java programmers are necessarily the best judges of good naming conventions. I've personally witnessed several of them immediately mention "gonads" when first hearing the term "monad".

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.

> There just isn't a direct relation back to the real world with a term like "monoid".

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.

Reply on news.ycombinator.com