A monad is a box that can contain a value. You can run an operation on the value inside the box.
An example of a monad is the Option monad: the box can either contain a value or it can be empty. The monad operation in this case modifies value in the box, or does nothing if the box is empty.
Another example is the IO monad, you can think of the box in this case as representing "the state of the world". The monad operation can modify the value in the box, but it can also write in sharpie on the outside of the box (perform IO)
In general a monad is any data structure where you have some boxed value and you can operate on the value without opening the box.
I'm not an FP expert by any means, but isn't having a flat-map operation (i.e. being able to combine two monads together, with result being another monad) a defining part of being a Monad?
I am not answering the question because after years of reading Haskell tutorials, I no longer have any faith that there's a particularly good way to explain what a monad is.
However, I will say, you don't need to know what a monad is to write Haskell effectively. The Option type is easy to understand. The IO type is... slightly more difficult to truly grok, but you can get pretty far without grokking it, and you still don't ever need to use the word "monad" to grok it*.
And here's my hot take: I've yet to ever come across a monad where knowing it was a monad was helpful in understanding it. As far as I can tell, "monad" is actually just a useless concept. The fact that some seemingly unrelated types are monads is vaguely interesting, I guess, but that's all it is. Lots of people (including myself, at one point) get stuck on monads for way too long--it's a major barrier for most people trying to learn Haskell, and getting past this barrier doesn't actually serve any purpose except that you stop wasting time trying to get past it.
Just to be clear: monads are useful. But, they're just as useful if you don't know you're using a monad, as they are if you do know you are using a monad. Knowing something is a monad doesn't make it more useful. Not knowing something is a monad doesn't make it less useful.
If the goal of the Haskell community is to filter their membership to those who think obscure type concepts are cool, then by all means keep talking about monads. But if the Haskell community is trying to increase adoption and communicate a functioning understanding of Haskell, the best thing they can do is stop talking about monads.
And if your goal is to learn to solve problems with Haskell, the best thing you can do is ignore monads. You'll understand them eventually with enough examples, but if you're like me, your reaction to understanding monads will, be "Oh, that's all? I can't believe people are talking about this."
* I'm saying "grok" to mean "understand in a way that allows you to use the concept in every situation where it can be used and in every way that it can be used".
That makes no sense to me. Monad shows up in the type signature of a number of functions, so you can't just ignore the typeclass?
Same goes for do notation which you can only use for monads (except if you use ApplicativeDo). I mean, I guess in many cases you can use Applicative instead of Monad, but I'm not sure that Applicative is easier to understand.
If your point is that you don't need to learn CT to understand how monads work in Haskell, or that you don't need to obsess about proving monad laws, then I agree.
But the fact that you can abstract over different types in such a way that something like Monad falls out as a language concept is what makes Haskell an unusual language compared to most others. If you want to just use individual monad instances without being able to generalise over them, you can use any other programming language.
it's a mathematical concept that can be applied to many things including programming. It's a construct in Category Theory that when *applied* to programming becomes a way to chain computations together that depend on some computational context.
In a practical sense, a Monad is an abstract interface that once implemented defines its own chaining and execution behavior. It can be implemented several ways, but the main idea is that it chains computations inside of their context. There is more to be said about why it's useful and all that, but in summary it became useful in mathematical style programming languages.
The reason Monads are confusing is because there is no distinction between the mathematical concept (which requires CT foundation to understand), and the implementation in programming which was derived from CT. That said, there is no usefulness to a Monad, without the underlying mathematical understanding, at least in my opinion, because the whole point of it is to use it with other CT concepts to create a robust program that is leveraging mathematical laws.
Typeclassopedia is a classic for getting a rock solid understanding of the "hard concepts" in ordinary (and beyond) Haskell. https://wiki.haskell.org/Typeclassopedia
13 comments
[ 3.8 ms ] story [ 22.8 ms ] threadAn example of a monad is the Option monad: the box can either contain a value or it can be empty. The monad operation in this case modifies value in the box, or does nothing if the box is empty.
Another example is the IO monad, you can think of the box in this case as representing "the state of the world". The monad operation can modify the value in the box, but it can also write in sharpie on the outside of the box (perform IO)
In general a monad is any data structure where you have some boxed value and you can operate on the value without opening the box.
"A value in a box" is more like a metaphor for a functor.
The key part about monads is that you can "merge the boxes" (to strain the analogy). Or, as I'd prefer to think about it, to merge different effects.
I was expecting this answer :)
However, I will say, you don't need to know what a monad is to write Haskell effectively. The Option type is easy to understand. The IO type is... slightly more difficult to truly grok, but you can get pretty far without grokking it, and you still don't ever need to use the word "monad" to grok it*.
And here's my hot take: I've yet to ever come across a monad where knowing it was a monad was helpful in understanding it. As far as I can tell, "monad" is actually just a useless concept. The fact that some seemingly unrelated types are monads is vaguely interesting, I guess, but that's all it is. Lots of people (including myself, at one point) get stuck on monads for way too long--it's a major barrier for most people trying to learn Haskell, and getting past this barrier doesn't actually serve any purpose except that you stop wasting time trying to get past it.
Just to be clear: monads are useful. But, they're just as useful if you don't know you're using a monad, as they are if you do know you are using a monad. Knowing something is a monad doesn't make it more useful. Not knowing something is a monad doesn't make it less useful.
If the goal of the Haskell community is to filter their membership to those who think obscure type concepts are cool, then by all means keep talking about monads. But if the Haskell community is trying to increase adoption and communicate a functioning understanding of Haskell, the best thing they can do is stop talking about monads.
And if your goal is to learn to solve problems with Haskell, the best thing you can do is ignore monads. You'll understand them eventually with enough examples, but if you're like me, your reaction to understanding monads will, be "Oh, that's all? I can't believe people are talking about this."
* I'm saying "grok" to mean "understand in a way that allows you to use the concept in every situation where it can be used and in every way that it can be used".
If your point is that you don't need to learn CT to understand how monads work in Haskell, or that you don't need to obsess about proving monad laws, then I agree.
But the fact that you can abstract over different types in such a way that something like Monad falls out as a language concept is what makes Haskell an unusual language compared to most others. If you want to just use individual monad instances without being able to generalise over them, you can use any other programming language.
In a practical sense, a Monad is an abstract interface that once implemented defines its own chaining and execution behavior. It can be implemented several ways, but the main idea is that it chains computations inside of their context. There is more to be said about why it's useful and all that, but in summary it became useful in mathematical style programming languages.
The reason Monads are confusing is because there is no distinction between the mathematical concept (which requires CT foundation to understand), and the implementation in programming which was derived from CT. That said, there is no usefulness to a Monad, without the underlying mathematical understanding, at least in my opinion, because the whole point of it is to use it with other CT concepts to create a robust program that is leveraging mathematical laws.
Monads in JavaScript.