This explanation is wrong on several fronts. 1. Your explanation of endofunctor is wrong! You say: "An endofunctor is just a functor (container that you can i

This explanation is wrong on several fronts. 1. Your explanation of endofunctor is wrong! You say: "An endofunctor is just a functor (container that you can implement map on) for which the type you start with is exactly the same as the type you end up with. For example, if you have an array of integers, apply a function to the contents with map, and you end up with an array of integers again, then you have an endofunctor ("endo" just means that it's the same on both ends). If you ended up with an array of strings, then it's not an endofunctor because an array of integers is different than an array of strings, even though they are both arrays." This doesn't make any sense, you are calling types functors and are saying that what determines whether a functor is an endofunctor or not is what functions you decide to apply fmap to! For example List is functor, List Int is not a functor anymore, it is just a type. And you claim that if xs is of type List Int, and you type fmap (x -> x2) xs then you "have an endofunctor" but if you typed fmap toString xs then you wouldn't have an endofunctor! To repeat xs is just a value, a list, List Int is a type, neither values nor types are functors, and a functor either is an endofunctor or is not an endofunctor it doesn't magically switch allegiance depending on what you use fmap for. Indeed, when Haskell functors are thought of as mathematical functors they are all endofunctors, functors Hask --> Hask (which makes them endofunctos since the domain and target categories are the same). 2. You misunderstood the sense in which a monad is a type of monoid! The monoids you mention (strings under concat, integers under addition) are monoids "for products", that is, the domain of the monoid operation is a product type: concatenation is a function String x String --> String, and addition is a function Int x Int --> Int. Monoids for products are the most important sort of monoids, but are not the only one and are not the sort meant when people say "a monad is a monoid in the monoidal category of endofunctors". There the domain of the monoid operation is not* a product of two types, but is rather the composition of a functor with itself. So a monad has a functor, say M, and comes with an operation M o M --> M (a natural transformation between the functors M o M and M). This natural transformation is the one called "join" in Haskell. I like your enthusiasm for explaning things simply, but I cannot let these bad errors go uncorrected. If you want to understand these category theoretical terms from a programmer's perspective, I recommend Bartosz Milewski's writings.