44 ms·

Monads are hard to explain because they name a pattern that most programmers have probably implemented before, but on the surface don't seem to have all that mu

Monads are hard to explain because they name a pattern that most programmers have probably implemented before, but on the surface don't seem to have all that much in common with other examples. It doesn't help that the terminology used to describe them is either very abstract/mathy, or complete gibberish (burritos and spacesuits? riiiiight...). Many monad descriptions read like talking about the botany of fruit in the abstract, rather than describing tomatoes and bananas and then what properties they have in common. You're on the right track about chaining and function composition. Monads remind me of Unix pipes, but with hooks for extensibility (such as Maybe's short circuiting), and with static checking of their guarantees. I also don't really care for Haskell, but I've implemented monads in Lua, OCaml, and Scheme.

Natsu 16y ago
It doesn't help that "bind" and "return" seem completely backwards to me due to knowing C. Even when I listed the properties in GP post, I see that I wrote it in a way that implies that they work the wrong way. No matter how I think about it, using return to put data into a monad just seems weird. Maybe I have to think of it as returning a monad? Which leaves bind. What do I have to imagine doing? Kidnapping the value and leaving the context behind? Burritos and spaceships indeed.
- silentbicycle 16y ago
  I tried to avoid the names entirely (also: ">>="?). I don't really use Haskell, though, so it's easy for me to just recognize when a monadic interface is a useful abstraction and leave it at that. Besides, a lot of languages have weird terminology.
  - gaius 16y ago
    Hmm, in Chapter 10 ==> means one thing and in Chapter 11 it means something different! CHapter 11 (Testing and Quality Assurance) being the buggiest so far... Oh dear.
- gaius 16y ago
  The "return" keyword in Haskell was poorly-chosen, it already has too much meaning in the imperative world associated with it. "inject" or "insert" or even "save" would have been much better.

Natsu 16y ago

It doesn't help that "bind" and "return" seem completely backwards to me due to knowing C. Even when I listed the properties in GP post, I see that I wrote it in a way that implies that they work the wrong way. No matter how I think about it, using return to put data into a monad just seems weird. Maybe I have to think of it as returning a monad? Which leaves bind. What do I have to imagine doing? Kidnapping the value and leaving the context behind? Burritos and spaceships indeed.

silentbicycle 16y ago
I tried to avoid the names entirely (also: ">>="?). I don't really use Haskell, though, so it's easy for me to just recognize when a monadic interface is a useful abstraction and leave it at that. Besides, a lot of languages have weird terminology.
- gaius 16y ago
  Hmm, in Chapter 10 ==> means one thing and in Chapter 11 it means something different! CHapter 11 (Testing and Quality Assurance) being the buggiest so far... Oh dear.
gaius 16y ago
The "return" keyword in Haskell was poorly-chosen, it already has too much meaning in the imperative world associated with it. "inject" or "insert" or even "save" would have been much better.