[acjohnson55]

In a typical imperative programming language, there's an "environment" that the actual lines of your program operate within. You can think of the environment as all of the sources your program can consume data from (files, databases, system clock, random number generator, keyboard, etc) and all of the sinks your program can write data into (files, databases, logs, the screen, etc).

Monads are an approach to modeling the idea of running a set of statements in a particular environment, with specific input and/or output capabilities, often called "effects".

In your typical programming language, you've only got one type of monad, which is the language runtime. You can do literally any type of effect at any time. That is very powerful, but it also makes programs difficult to reason about.

In many typed functional programming languages, monads are used to create much more specific contexts for running sequences of computations and effects. That makes reasoning about local sections of your program way easier.

One might think "why would I want to limit my power?" And the answer is you're only limiting yourself locally. It's exactly the same as how procedural programming dispensed with the all powerful GOTO, but it turned out that breaking programs into functions made them much easier to reason about.

And it turns out that once you start thinking that way, you can often offload some pretty tricky logic into a well designed monad.

A major caveat is that things can get pretty complex when you try to compose monads, and for me, that's where the love affair ended. There are alternative models for how to constrain effects, like algebraic effect systems, which try to be more intuitive and composable.

[goto11]

This describes some monads but not others. IO and State can be thought of as environments supporting effects, but it doesn't really make sense to think of a List like that.

The problem with many monad explanations is they only explain particular monads but then other monads become even more confusing.

[acjohnson55]

I've heard the List monad described as modeling nondeterminism as an effect. As you chain flatMaps, at each stage, you're consuming a discrete set of possible inputs and producing a new set of potential outputs per input.

So it's a little different from thinking of your program as something that is once. Instead, you have your program being run multiple times, with the environment injecting different at each stage.

I think the Future/Promise monad is similar. The environment is taking responsibility for pausing and resuming computation.

But I'm curious if you have other monads in mind where the analogy fails.

[goto11]

A ordinary list expression like [x + 2 | x <- [7, 9, 13]] is not effectful or non-deterministic. It is completely deterministic and have no side effects.

[acjohnson55]

Correct that there's no literal effect, but conceptually, if you wanted to model a particular sort of nondeterminism as a monad, you could use one indistinguishable from List.

And I think it holds just fine to think of the monad as injecting data into a sequential computation before each step and ingesting output after each step (boxed in the monadic container).

Which reminds me, that boxing is also part of the power of monads. It means you can nest steps of a monadic computation, instead of just chaining them, as a functor allows. This stimulates lexical scope -- bindings that exist for all statements after the one that defines them.