And the article introduces a whole lot more concepts, such as homomorphisms in order to be sufficiently interesting. I don't say that you can't build interesting stuff on top of monoids (I have several colleagues that are doing just that), just that the concept of a monoid by itself isn't very interesting or deep.

The goal of programming is to reduce all parts to such simplicity that they become boringly simple, and thus impossible to get wrong. Concepts are only interesting while we don’t fully understand them yet; when we’re done fully understanding them, they become boring and we move on to the next thing. Thus, the solution to programming is to compose programs out of boringly simple parts, using a boringly simple method of composition.

> The goal of programming is to reduce all parts to such simplicity that they become boringly simple, and thus impossible to get wrong.

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.

The main selling point is that reduction and "boring simplicity" can lead to a formally correct program, or at least one where most errors are caught by static analysis/type checking/etc.

I'm not saying it's not worth while, I'm just saying that it's not the goal (in general. Some academic exercises might have goals such as that because the point is to learn).

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.

And how do monoids play into this? This is just a vague generality; unless you can show exactly what more complex programming concepts you can reduce to monoids and how that helps with understanding programming, that doesn't mean much.

Sure. It's funny with these algebraic things. If they're simple, people complain that they're not interesting... but when you add some depth, people complain that it's too difficult!

"I don't want to have to understand abstract algebra to use Haskell!"

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

To be fair, it may not be the same people.

I'm sure it's not! But even so it's interesting to be caught between these two antipodes. As your probably know there's another group of people, Andrej Bauer among them, who provide a different antithesis to "I don't want to have to understand category theory to use Haskell!" by exclaiming "Haskell doesn't use real category theory!".

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