Monads as a Programming Pattern

When trying to map (or bind :) a monad to OOP/imperative programming, it strikes me as more straightforward to think that, e.g., the IO monad is an object that encapsulates the result of a network operation, together with some utility functions for dealing with the result and not having to deal with the unwrapping of the result. Kind of like Futures or Promises.

(Now, here the real FPers will say that the comparison is flawed because of certain FP desiderata like referential transparency, but that's beyond the extent to which I've internalized monads.)

What I've observed is that a lot of learning programming is about becoming comfortable with thinking of more and more concepts as first-class entities. Turning larger pieces of code, procedure, and patterns into object/values you can pass around, hold, create, etc.

1. small-scale one I see a lot is that many programmers don't realize boolean expressions produce values. Instead, they think they are syntax that can only be used inside control flow statements. It is a mental leap to realize that you can go from:

    if (thing == otherThing) { doStuff(); }
    moreStuff();
    if (thing == otherThing) { doLastStuff(); }

    var sameThings = thing == otherThing;
    if (sameThings) { doStuff(); }
    moreStuff();
    if (sameThings) { doLastStuff(); }

3. Closures are another big one where you take a piece of code and turn it into a value that you can delay executing, pass to other procedures, etc.

But for many people, they will be used to IO returning nothing, or error values they can ignore. So the case has to be made as to why you need a monad there at all.

(I've just had the slightly disturbing realisation that C++ streams are also monads .. the documentation never uses this term.)

If someone already can intuitively/naturally read Haskell syntax, they've likely already looked at a bunch of these tutorials and read about functor/map.

For those that you're targeting that don't read haskell syntax naturally, explaining something to someone in a language they don't speak is if zero use to them.

The above comment managed to make something people already know confusing.

Monoids are nothing but a design pattern generalizing string append and the empty string.

Functors are simply a design pattern generalizing "map()" over arrays.

Monads are simply a design pattern generalizing "SelectMany()" over arrays.

It turns out that these patterns are significantly more powerful than most programmers realize, and by learning the underlying design pattern you'll be able to recognize novel situations where you can apply them and write much better/simpler code and APIs.

Encapsulation? No one gets direct access to the state. Instead, there are methods or functions for dealing with the state indirectly, crafted to protect those outside.

Answer: wrap the entire external universe and all its messy state up into an object, then pass that down a chain of functions which can return "universe, but with some bytes written to the network" (IO monad)

Sounds like "Outside the Asylum" from the Hitchhiker's Guide to the Galaxy universe. Basically, someone decided the world had gone mad, so he constructed an inside-out house to be an asylum for it.

http://outside-the-asylum.net/

"A monad is a type that wraps an object of another type. There is no direct way to get that ‘inside’ object. Instead you ask the monad to act on it for you." How is a Monad anything different than a particular kind of object wrapper?

https://www.infoq.com/presentations/functional-pros-cons/