5 ms·
I like this post because it describes specific monads and why they are useful. If I were to recommend a basic path to understanding monads, I'd say do this: 1
by phamilton 12y ago
I like this post because it describes specific monads and why they are useful.
If I were to recommend a basic path to understanding monads, I'd say do this:
1. Understand `map` in the context of lists. This can be done in Ruby or Scala very easily if you don't want to get into Haskell directly.
2. Learn about the Maybe monad (or Option in scala). Understand what mapping an Option or a Maybe means. A simplified explanation is to compare it to a list of either length 1 or 0.
3. Learn about the IO monad in Haskell. Understand how IO monads can compose. At this point, it's ok to just say magic happens and the compiler then cause a single IO monad (the result of composing multiple IO monads) assigned to main to execute and the side effects will happen.
At that point, you've got a general understanding of how to use monads. It will actually take you pretty far.
One key point that might be a hangup is going from `map` meaning "apply this function to every element and return a new list of the results" to `>>=` meaning "apply this function as dictated by the monad and return the result". It's probably good enough to acknowledge that `map` is a simplified case of `>>=`.
In any case, as the linked article says here, you should be able to understand specific Monads fairly quickly. Perhaps truly understanding monads means knowing when to create new monadic structures but that's hardly a prerequisite to being productive with monads.
- dllthomas 12y agoI think your description here is likely to be tremendously confusing, and I don't recommend anyone who doesn't already grok functors and monads read it...
- phamilton 12y agoMy point is that you can actively use Lists and Options in Scala and be using monads without having any idea what a functor or monad is. I believe that's a similar point to the article. It's easier to understand how to use specific monads than to understand the mathematical definitions of functors and monads. Knowing `fmap` is essentially distributive isn't necessary to use functors and get a feel for what they provide.
- dllthomas 12y agoI understood your point. I think you were unclear about what behavior belongs to monad, in a way that will confuse newcomers. "map" (or "fmap") belongs to Functor; monads have it because they are functors. I agree that starting with the laws doesn't necessarily makes the most sense, and that they're not necessary (though can be valuable) for use of these things... but you do need to introduce the laws early enough that they're understood by the time someone goes to write their own instances of the relevant typeclasses - otherwise they're going to get bit by something that assumes the laws hold, and they're not going to understand why.
- vertex-four 12y agoHaskell's IO monad is decidedly not useful outside the context of Haskell and pure functional programming, both of which I do not find fun. Are monads in general useful outside that context - for example, in mostly-imperative languages like Rust?
- olavk 12y agoThe IO and State monads is specifically to solve the problem of side effects in a purely functional language, so they are not really relevant in other languages. But other uses of monads, like say monadic parsers could be useful in other languages. And list comprehensions is also based on a monad in Haskell - this functionality is clearly useful in many other languages. But without some kind of syntactic sugar (like do-notation in Haskell) the use of monads becomes far to cumbersome, and it ends up being easier to solve the same problem in an ad-hoc manner.
- fubarred 12y agoCheck out https://youtu.be/xKRndVoo2ms https://youtu.be/xKRndVoo2ms, it explains how monads can refactor messy things like call chaining if you're building SQL-like result interfaces.
- 12y ago