You have a value of a certain type.

You have another value of the same type.

If there exist a function (let's call it "combine") that combines those two values and emits a third value of the same type.

AND

There exists a value of this type that does nothing when used as argument to this "combine" function.

then your type is a monoid. (basically)

You left off the associativity; you need (a + (b + c)) == ((a + b) + c), where + is the combining operation.

I did. I left it out for two reasons: - the comment asked for a "simpler" explanation and associativity isn't a specially simple concept if you are not familiar with it and does not really help understand the core idea of a monoid. - in practice, monoid associativity isn't checked. Most type system aren't able to express it. Therefore, whenever you encounter a monoid you have no guarantee that it is indeed associative.

There may be no guarantee, but that doesn't make a structure without associativity any more of a monoid, nor is having an identity element without associativity the core of idea of a monoid. If anything, associativity is the more important part of the concept since without an identity element, you are still left with a semigroup.

A bit of advice about understanding concepts like these:

You don't understand every single instance. You understand the concept, and then you begin to learn individual instances.

The shape and the use of monoids is really easy to grasp. Sometimes understanding how a thing is specifically is a monoid or how it's implemented can be obscure. They are similar to monads in this respect, although often less complicated.

In summary, understand that there is a beach and that the beach is made of many grains of sand. Each grain of sand may not be obvious from just staring at the beach.

People are awful at explaining Monad-related concepts. I think everyone starts with a reasonable explanation and then tweak it to be more succinct until they end up "a monad is just a monoid in the category of endofunctors"

This article is about Monoids, not Monads. Monoids are simple. Just imagine a bunch of things, and imagine you can "combine" any arbitrary thing to another thing. The combination has the property of being associative (whatever) and you're only allowed to called it a monoid (otherwise convention says you need to call it a semigroup) if there is also an item (the "identity" or "neutral" element) which when you combine it with any arbitrary item, produces that same item as a result.

Common examples are: strings which you're allowed to combine with concatenation (with the empty string being the "neutral" element). Integers with addition as the combiner is also a monoid that also has a few additional named properties (like commutativity and existence of inverses) but they're still monoids.

By "monad-related concepts" do you just mean abstract algebra? Otherwise, how are monoids and monads related, other than that they are both algebraic structures?

My comment was pretty poorly written, and is probably better understood in terms of just "explanations of things starting with mon-" :-D

The concepts aren't tough, people are just pretty bad at putting themselves in the shoes of a learner, and throw bizarre over-complicated descriptions and examples into the mix when explaining them. The description I gave is someone's tongue-in-cheek stab at these which has stuck with me (unless I'm horrendously off and that is actually someone's legit attempt to describe monads)

I summarized a decent Reddit thread on the topic a while back here: http://metaleap.net/blog.hasplained-monoids.html

It's a stupid over-complication of stuff you do every day while programming. It's these annoying science-y, elitist words that keep people away from programming.

A monoid is just an operation you perform on things that are similar. The concat() function in JS is a monoid.