If you type-check your Python/JS/Ruby code, monads are a functional-style solution to get rid of that code (functional programmers don't like type-checking).
That's my simplest explanation at least!
type Burrito = Meat option \* Ingredient list
let (>>=) burrito f =
match burrito with
| Some meat, ingredients -> f (Some meat, ingredients)
| None, _ -> None, []
let returnBurrito (meat, ingredients) = meat, ingredientsYou have an array of state, and you can call a method on it that returns a new array of state, that you can call a method on, that returns a new array of state, etc. And that concept of doing state -> function call -> state is the holy Monad.
A JS pleb would write instead:
burrito = (new Tortilla()).addMeat(Chicken).addMissionBurritoIngredients().holdThe(Cheese)
No one would be confused about what was going on, and it would be basically the same thing.
While it is just functions. To say, it's just functions all the way down, doesn't help you talk about them.
Could say that math is all functions, and having some language to discuss that subject is maybe more the purpose of the monad.
Kind of like if you were to say to a math student, just go study functions, no need for any school or language to describe what is happening.
But yes, category theory is a bit heavy handed to a programmer just needing to chain some functions.
Maybe the problem is such a vast gulf between the junior dev just needing to know how to chain some things, and the category mathematician that has never coded. Yet they are circling around the same subject.