fold :: (Monoid m, Foldable t) => t m -> m

I actually did a count recently; something like 30% of our modules import Data.Monoid. Many of them were just using the (<>) operator, but that's useful in and of itself: no need to define a distinct operator for each of our types that wants one.

It's a simple, incredibly general abstraction that pulls its weight—partly because it doesn't have much to pull.

http://repository.upenn.edu/cgi/viewcontent.cgi?article=1773...

No, that's a strategy to achieve a goal of programming. Programming is about using machines that accept well defined instructions to automate processes for people. A complex and poorly understood program that still ends up reducing the overall amount of work required for individuals is still worthwhile, even if not reduced to being boringly simple.

It's sort of like saying the goal of owning a store is to match inventory to sales as closely as possible. That's a strategy or sub-goal towards reaching the real goal at best, which is to make enough money that the store pays for itself and hopefully supports the owner. Some stores don't even have inventory, so that strategy doesn't even apply to them. Similarly, that programming strategy may not apply well to some problems (and some problems cannot be proven formally correct, at least in whole).

My original reply was really just meant to point out that what they viewed as the goal of programming, is really just one of many competing strategies for producing software, and many others don't care about that at all.

"Abstract algebra is too simple to bother writing programming blogs about!"

It's just generally quite amusing to be caught in the middle of all this.

That's irrelevant, because we are not naming them to use them in abstract algebra, but as abstract constructs in a different domain with its own complexity (programming).

You'd be surprised. A pointer (as in C) is an even simpler notion, but the complexity it represents to new programmers is big.

Complexity in a programming element from the interplay it has with everything else -- not from it isolated.

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