EXPLAIN MONADS TO ME OR I'LL FUCKING KILL YOU! DON‘T DUMB IT DOWN INTO SOME VAGUE SHIT! EXPLAIN MONADS TO ME RIGHT NOW OR I'LL LITERALLY FUCKING KILL YOU! WHAT THE FUCK IS A MONOID? WHAT THE FUCK ARE ENDOFUNCTORS? DON'T DUMB IT DOWN OR I'LL FUCKING KILL YOU
This is a good video iirc: https://youtu.be/ZhuHCtR3xq8
Now I don't really know about functional programming and I haven't ever spent much time studying category theory, but from a math perspective, the simplest way I can summarize it is this:
First you have to understand what a category is. A category is a bunch of objects, and a bunch of functions between these objects, or "arrows" going from one to the other object (direction is important).
Then you have to understand functors. You can imagine a functor as some kind of "function" that takes objects AND arrows from one category to different objects and arrows of another category (these arrows are called morphisms, they are like functions, although there is an additional requirement that they have to preserve the structure between objects, not gonna go into it here). But the important thing that makes them functors is that a functor preserves the link between objects. So say that a category has two objects, A and B, linked by a green arrow that goes from A to B, and another category has C and D linked by a blue arrow that goes from C to D and another element F that is linked to C with a red arrow that goes from C to F. Now if you have a functor that takes A to C and B to D, then the green arrow has to go to the blue arrow, because if it goes to the red arrow, then the link wouldn't be preserved. Similarly, if instead of D, B was mapped to F, the green arrow would have to go to the red arrow to preserve the link. It is easier if you draw all this.
Now, as I said before, direction matters. So if you have a category A->B and a category C<-D and you try to make a functor that takes A to C and B to D, you can't do it, because you'd have to take the arrow to another arrow that goes from C to D, but you only have an arrow that goes from D to C available.
So now if you understand functors, an endofunctor is simple. It's just a functor that takes stuff from a category to an exact copy of the category. So maybe there are objects A and B in a category, and your endofunctor takes A to B and B to A, while obeying all the rules with arrows I explained before.
Now, there is a special endofunctor called the identity functor. That is simply an endofunctor that doesn't change anything. It takes A to A, B to B, arrows to themselves, etc. It is important to remember that each category has its own identity functor.
Finally, there are natural transformations. This is a little bit more complicated so I suggest you open wiki, go to the definition and take a good long stare at the commutation diagram after I explain this, and try to figure it out. Also draw shapes.
I described before how functors connect categories. So functors are kinda like an arrow between two categories, right? Well, you can define a family of morphisms between two different functors, and it has to be such that the structure of the functors is preserved. What does that mean? It means two things. Let's say we have a category C and another D, and two different functors going from C to D, which we name F and G. Remember that F takes any object X of C and takes it to an object F(X) of D, as well as any arrow (morphism) f of C to an arrow F(f) of D. Then our natural transformation is a family of arrows between F and G such that:
For every object X in the category C, we have one morphism in the family that goes from F(X) to G(X). Remember that F(X) and G(X) are objects in D.
The morphisms belonging to the family of the natural transformation are such that for every arrow f that goes from X to Y and which lives in C, if one goes via the natural morphisms from F(X) to D(X) and then uses the functor G(f) to go to G(Y), then it is the exact same thing if you use the functor F(f) to go from F(X) to F(Y) and THEN use the appropriate natural morphism to go from F(Y) to G(Y), they are merely different roads.
So essentially a natural transformation is a family of instructions that tell you how to change a functor from C to D into another functor from C to D, in such a way that everything is nice and properly connected, like changing the color of a chain instead of breaking it and connecting a bunch of disparate loops together. Hence the name natural. Functors which are connected by a natural transformation thus have some kind of similarity, a kind of similar "shape", or structure.
A monad is a package deal, it is an endofunctor T (which is often itself called a monad, names are weird, I know) plus two different natural transformations. The first one goes from the identity functor of the category C, to the endofunctor T. This hints that T is kind of "similar" to the identity in structure which isn't to be taken too literally, but it does restrict a lot of the possibly wild behavior it can have. The other natural transformation goes from T^2 to T. What is T^2? It is the composition between T and... Well... T again. Essentially it tells you go from category C to C again through T ("rearrange" shit), and then do the same thing yet again. It is actually these two natural transformations that are the important constituent elements of a monoid. To have a monoid you need to have a category T (in this case our category is an endofunctor, it is a bit weird I know) a morphism such as the first natural transformation we call η, and another one like the second we call μ.
But this is not enough. The two natural transformations described also have to obey 2 conditions called coherence conditions. And fuckkkk I'm not gonna explain these now because I just realised I got shit to do and this is taking wayyy too long so yeah, if you have any questions I will elaborate and answer later.
I actually understand monads more or less, I just posted this as a meme. But thanks a lot for your effort, this could be very useful to someone
Heyy no problem, are you from a programming or math background?
Yeah, I'm a software engineer and also have interest in math
Yeah, I guessed so... All these Haskell kids with their monads, no one is in it for the pure math in our day and age >:(