My original argument (in this thread above) is that identifying patterns like monoids (and monads) gives more power through better abstractions.
Not that it's simpler than not knowing those abstractions (obviously assembler which ditches all abstractions is as simple as it gets conceptually).
>What aspects of associative operations with a neutral element are so central to teaching programming that naming such a construct "monoid" gives us a stepping stone towards better understanding programming?
It's about unifying similar usage patterns and having a mechanism to treat things like optionals (Maybe), errors, IO etc in a uniform way.
As a simplified no-monady example, consider languages with a string distinction between primitives (ints, etc) and objects (like Java, at least before generics/auto-boxing). A language that comes and treats both of these things (primitives and objects) as the same -- all objects, is an eye opener, and allows for more kinds of expressions than a language that treats them as distinct kinds of variables does.
The argument as I see it written is only that naming them reduces cognitive load. I don't see anyone suggesting that the specific name they happen to have carries any special power.
* Under my Foo API you are able to combine Bars monoidally
* Under my Foo API you are able to combine Bars using baz such that `baz (baz bar1 bar2) bar3 == baz bar1 (baz bar2 bar3)` for all `bar1, bar2, bar3 :: Bar`, and also `baz == Bar quux baz == Bar baz quux` for all `baz :: Bar`.
It's incredibly useful, since you can just go into Hoogle or some similar tool and query a function that:
Monoid m => (a -> m) -> [a] -> m
1 - Well, the autodoc write those comments for you.
Associativity is a boring word, because high-schoolers have seen it.
Eh. Your patience here is admirable.
Every time `instance Monoid Foo` occurs in the Haddock documentation of a Haskell datatype which is pretty often!
> Does the frequency with which this occurs justify introducing new terminology?
"Justify" according to what set of criteria? Personally I prefer it.
> you artificially inflated the wording to make "x is associative and has a neutral element y" look more complicated than it actually is
So your suggestion is
* baz is associative and quux is a neutral element for it
Really, if you're going to go that far you may as well go all the way and just say
* Foo is a Monoid under baz and quux
> while not even naming in your "short" case what the operation and neutral element are.
Well, in the Haskell world they're implied by the typeclass instance, but I take your point.
(Though normally the latter would be more like "`quux` is a noop", "`quux` is an empty set", or whatever domain-specific term you need, and the associativity claim would be a brief parenthetical inside meaningful documentation.)
I think jQuery satisfies monoids most of the time, and it worked and could be explained just fine without saying the word "monoidally" even once.
[1] From Jabberwocky, of course
"Under my Foo API, Bars are combined associatively".
Associativity is a word. It's also a word that is taught to people in high schools. So use that.
Also, the elements are still combined associatively. With closure and and identity properties, the set forms a monoid under this operation. "Monoidness" is not a property of operation (in a way that the language is usually used, at least in math).
For that matter, "combine monoidally" is a phrase that has 2 Google hits at the moment, which indicates to me that in real life, you still have to resort to less-shiny words to describe things.
There doesn't seems anything hugely objectionable to me in saying "Bars combine monoidally". But if you prefer, one can say "Bar forms a monoid under baz and quux".
It may not be obvious to you that it increases simplicity merely to combine two words into one but across an ecosystem of perhaps a thousand Monoid instances it indeed is.
But seriously, the use of Bar/Baz etc. in this example makes it more convoluted, rather than less, precisely because the names offer no hint for how to understand the nature of each thingy.
No. Firstly, Bars may not be commutative. Secondly, would you really say that taking the unions of sets is "just like adding numbers"?