Ask HN: Does anyone know what a monad is?

Kagi says: A monad is a concept that appears across multiple domains—philosophy, functional programming, spirituality, and cosmology—with different interpretations in each context.

Not a burrito?

The time-honored way of learning about monads is to write a monad tutorial. Monads provide an order dependency (that along with some hidden strictness for I/O and the like) which allows the side-effecting to be isolated from the "pure" functional side of things. The purely functional Clean language had an explicit "world" variable that you could pass around to whatever side-effecting functions you wanted. And it had uniqueness typing so that you couldn't accidentally refer to the same "world" twice. You can think about monads as being a way to hide the crufty "world". A lot of the mystery around monads comes simultaneously with a whole bunch of other newness in learning Haskell (lazy evaluation, HM type system, differing syntax, algebraic data types, currying and partial application, functional programming, etc.).

https://en.wikipedia.org/wiki/Clean_(programming_language)

I'm not a Haskell expert, but I dabbled quite a bit. This is my explanation of what monads are that doesnt rely on math lingo and understanding the maths behind it. I don't fully understand myself but maybe thats actually helpful for trying to explain to someone not familiar with the concept. My understanding relies on concepts used in other programming languages. So depending on how familiar you are with them, this might or might not be helpful for you.

A monad is kind of like a generic class to boxes that adds additional logic to the data it boxes without actually caring about the data itself.

My goto monad for that concept is a linked list and the map operator. So an instance of the linked list might be Node(5) -> Node(7) -> EmptyList. Now let's call map with a function f(x) = str(x) + " * 2 = " + str(2x). This gives us Node("5 2 = 10") -> Node("7 * 2 = 14") -> EmptyList.

Now let's separate the monad from this. The monad is the structure and logic around the data and the function that we provide. The monad doesn't care what data it holds and is doesn't care what function we provide. It only defines the structure and how functions are applied to the data it holds.

My personal alternative take to the usual monad tutorial — greatly simplified:

"Functor", "Applicative", and "Monad" are all just generalizations of the concept of `map` and `flatMap`.

  1. Something is a "Functor" if you know how to call `map` on it, nothing more. "I can take a box of things and turn it into a box of other things, 1-to-1". On lists, for example, this is just `map` itself
  2. Something is an "Applicative" if you know how to call `map` on it, but also know how to take a non-boxed value and put it in a box, and also know how to combine boxes in order
  3. Something is a "Monad" if you know how to do all of the above, but also know how to call `flatMap` on it, nothing more. "I can take a box of things, turn each thing into a new box, and then combine them all in order". On lists, for example this is just `concatMap`

There's nothing really more complex to it, besides how you squint at various things (like functions) to fit them into the concept of `map` and `flatMap`.

To answer your questions more directly:

  1. Monads themselves are neither necessary nor sufficient to perform side effects in Haskell; they don't directly enable the effects, but they *do* help place guardrails on the actual unsafe, low-level code which *can* perform the effects, safely and in an ergonomic and composable way
  2. Yes, "Monad" is just a name for a recurring way to approach a problem. Like in most math and programming, a certain repeating pattern was noticed, and given a name. Because of the math origin of the term, you get "Monad" instead of "flat-mappable"
  3. Like any other tool, you reach for a monad when you have a monad-shaped problem. They're just one (powerful) tool for solving certain problems

a punching bag sort of enemy in cave of qud