3 ms·
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 wha
by kerkeslager 4y ago
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".
- Tainnor 4y agoThat 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.
- deleted 4y ago[deleted]