Something I've been wondering for a long time that no one seems to be able to explain is "what the fuck is a monad?" and why is this seemingly the one question about programming that is inadequately answered
It's a pattern that recurs in lots of different programming environments. It's an abstract pattern, so it confuses people who've never encountered them, and then they go out and read a bunch of terrible monad tutorials which obscure what's really going on.
Programmers are good at abstract patterns though! Look at iterators: they're obscure and complex if you've never encountered them, but now they seem really easy. The same is true with monads.
I'm willing to bet you've read 10 plain-english perfectly-adequate explanations of monads that explain them fully, and you've rejected them because they don't seem hard enough.
A monad is an abstraction pattern that, as applied in typed functional programming, has three parts.
1. A type constructor that takes a type and returns an type. Enough languages have an Optional construct now that this should be sensible to anyone paying attention.. If Integer and Optional<Integer> are types that have values, Optional is a type constructor.
2. A function for injecting a value in an appropriate manner. To stick with java-ish syntax, it'd look like Optional<T> inject(T x) { ... }.
3. A function for binding a function to a value with appropriate types. Optional<R> andThen(Optional<T> x, Function<T,Optional<R>> f) { ... }. This function has a couple restrictions on what it's allowed to do which are called the "monad laws". It's not really worth burying yourself in them. The important part is that they have the effect of requiring inject and andThen to do the absolute minimal thing that works sanely.
This really isn't complicated. It's a super-basic pattern. It keeps getting reinvented over and over in languages with first-class functions.
So why do you not hear about it outside of typed functional languages? Because very few languages give you the flexibility to work with this abstraction. In Haskell or F#, you can write code that works with any monad. In Java or Rust, you can only write code that works with a specific type. The missing abstraction capability makes the abstraction academic only. And since it's so simple, there's nothing in particular to be gained by talking about the abstraction when you can't use it.
People have made a huge deal out of monads, but they're really not complicated. Thinking they're hard or hold the secrets of the universe is like thinking the Iterator interface is hard or holds the secrets of the universe. Sure, maybe a language has some syntactic sugar to make it easier to work with them (do-notation in Haskell, for loops in Java). But it doesn't mean there's anything complicated going on.
Note the things absent from this response: IO, side-effects, purity, sequencing, basically any use case. None of them are related to the definition of monads. None of them require monads. Monad is an abstraction. It doesn't let you do anything new. It just lets you share vocabulary (and code in more expressive languages) between many disparate areas.
A useful way to think about it for me coming from imperative/OOP programming was that a Monad is like a well behaved (governed by laws) interface.
I found solace in telling myself "The word Monad is meaningless except for the fact it tells me this abstract thing behaves according to these laws and I can use a set of standard API's and functions on it".
Languages like Haskell provide a large API for using regular functions with Monads, combining Monads together, sequencing them in different ways, and much more.
Just a function that returns a value of the same type. The value comes from mean nasty state modifying and/or over the network. It is the function programming portal to real world, encased in a pretty function you can reason with.
