OK, the basic idea is that you have two functions, `f_1` and `f_2`, of type `a -> a`, and you want to run them both on an input value `x` to get an output `y`.

OK, the basic idea is that you have two functions, `f_1` and `f_2`, of type `a -> a`, and you want to run them both on an input value `x` to get an output `y`. You can think of `f_1` and `f_2` as a data pipeline that `x` passes through and then the output comes out the other end. So, y1 = f_1 x y = f_2 y1 -- or, y = f_2 (f_1 x) But what if you have an arbitrary list of functions as your pipeline? y = f_n (f_{n-1} (... (f_2 (f_1 x)) ...)) Well, the solution is that functions of type `a -> a` are composeable, so you can 'add them up' as if they were real values (which they are). The Haskell function composition operator is `.`, so: y = f_2 (f_1 x) -- is the same as, y = (f_2 . f_1) x Now, how do you go from 'composing two functions' to 'composing a list of functions'? Well, monoids are a typeclass (a statically-enforceable design pattern) that encode the idea of being able to combine two things into one, and 'for free' give you a function `mconcat` that combines a list of those things into one. So if you have a monoid instance for functions of type `a -> a`, you're now able to combine many of them together, get a single composed function, and apply your input value `x` to that. `Endo` is just a fancy name for 'function of type `a -> a`'. I agree to a large extent that all this category theory stuff can get distracting. I personally think type theory is a much more rewarding field of study. To 'endomorphism', a type theorist would say, 'Oh, you mean `a -> a`?'