God, you guys are idiots, it’s so simple
- You take a Function
- ???
- Result It can’t be simpler /s
No joke that’s pretty much every example I came across trying to get my head around it :D.
Not sure if using analogies is helpful or just going to be more confusing but, the way I think of a monad is similar to how I used to cook back when I worked in restaurants. I’d prep all my ingredients in small containers so I wouldn’t forget anything, and they’d be ready to go when needed. Then I’d start adding them to the main mixing bowl, one step at a time. If I forgot an ingredient or accidentally flipped the bowl, the recipe would fail — you can’t keep baking after that.
So a monad is like that bowl: if you mess up, it just dumps everything out and resets your little prep bowls, instead of letting you keep going and make a batch of shitty cookies
The “main-bowl” is the monad (the context that holds your values).
The “prep bowls” are the individual values or functions ready to be chained.
The “dump/reset” is the idea that once something goes wrong, the chain stops safely.
And “shitty cookies” are the result of not putting a monad in place and just sending it.
Maybe someone with a more diverse programming background can explain it better. But it’s basically a function checker usually wraped in IF ELSE and RETURN.
Some pseudo code in case my analogy doesn’t make sense.
def main(): bowl = get_flour() bowl = add_butter(bowl) if bowl is None: return "Recipe failed — restart!" bowl = add_sugar(bowl) if bowl is None: return "Recipe failed — restart!" return bake(bowl)I like your explanation, that makes a lot of sense
Isn’t your example just the builder pattern?
Yeah, that explanation is missing the critical point of generically applying external functions through
flat_map/bindI think this is a good explanation: https://fsharpforfunandprofit.com/rop/
A monad is a builder that lets you use previous partial results to make decisions while you build.
that sounds like a regular builder
If you regular builders can’t be composed as values…
That may be regular, but it doesn’t make them good. Some times you need that, and it’s ok, but that shouldn’t be most times.
Seriously, can someone please explain monads like we’re dumb or something ?
I liked this explanation:
It’s like a burrito
Monad is (a classes of type of) a collapsible container. Collapsible, like how you can flatten a nested list, or Option<Option<A>> can be flattened to Option<A>.
A common pattern with monads is the flatMap function, where you apply function A -> List<B> to (each element of) List<A> to obtain List<B>. This happen to represent erroneous call chaining with Option or Result types.
This is probably the best explanation I’ve seen:
http://adit.io/posts/2013-04-17-functors,_applicatives,_and_monads_in_pictures.html
@mEEGal @ZILtoid1991 Honestly, the best way I’ve found to understand monads (if we’re talking Haskell) is to look at the type signatures of its functions. Understanding
return,(>>=), and(>>)will essentially tell you everything you need to know.I’m not good at this but that’s never stopped me from making a fool of myself before.
Iterators are monads because they have a
flatMapon them. It takes each element and spits out a new iterator which is merged in to the result.Option is a monad too. Same reason. You can map the contents to another option. And you won’t get called if there’s nothing inside.
Promises are monads too. You can map the result to another promise. The wrinkle here is that you don’t get to know when the map happen. Or it might not get called at all if the promise errors out.
IO can be a monad because you can ask it for input and wait for the result. It’s just the same as a promise.
See how these different things share a common behavior? That’s monad. Or, maybe it’s monoid. Names are hard and I’m busy making a fool of myself.
Monads are nothing more than a useful abstraction. Haskell is famous for them because they couldn’t make Haskell do imperative stuff without them so they spread them all over the language.
We all use them every day in regular programming. We just don’t think of them as a class of thing.
Here: https://fsharpforfunandprofit.com/rop/
A very practical and tangible walkthrough
http://blog.sigfpe.com/2006/08/you-could-have-invented-monads-and.html
It’s a “programmable semicolon” or “decorated-function composition”. I think most people that are confused about it, are trying to make it be more meaningful than it is. Haskell (?) just grabbed a math name so they’d have one word for it, because it’s a useful class name there.
Do you know C#? LINQ? IEnumerable<T>? IEnumerable<T> is a monad. That’s how LINQ works.
You’ve been using monads all along.
Or for those using Java: Stream<T> is a monad
Optional is my favorite example to give, at this point most people have internalized how to use its map function and how it works
That’s a good one.
A rule of thumb is that if it has map and flatMap (or equivalent), then chances are that it’s a monad.
Monads are just a monoid in the category of endofunctors. If you dont understand that, skill issue
Tap for spoiler
/s
I know! That’s the Greek mythology thing.
You should crosspost this to !philosophymemes@quokk.au
Isn’t it just like error handled code in Golang?
Like a sequence A, B, C where if A errors you don’t continue to B or C but if A is ok then you just continue doing B and so on. In the end you end up with the result or errors. Am I wrong to assume this?
The Either monad (also known as Result) provides Go-like error handling, but automated. You only check manually for errors after the last call, the monad handles the process.
But this is just one example of a monad, there are many more.
Whenever I try and get a proper explanation of a monad from the internet I get these miserable opaque examples which make me go “sorry I asked!” But I think a monad is basically just single type that when unwrapped gives you the result of a calculation and some metadata about the calculation.
I think it’s more like Rust’s Result or Option types then go’s tuples but I’d say they both basically count.
