4 ms·

> It’s interesting, of course, but far from necessary. I think this right here is where a lot of people go wrong with understanding them. Really, the best way

> It’s interesting, of course, but far from necessary. I think this right here is where a lot of people go wrong with understanding them. Really, the best way to get them is to work directly with them. The mathematics is orders of magnitudes more abstract than the actual practical aspects of using monadic functions.

bradrn 5y ago
Completely agreed. The only way to learn about monads is to (a) see them being used in examples and (b) use them yourself — exactly like every other concept in programming. Just seeing an abstract explanation is not nearly enough.
- exdsq 5y ago
  Worked on a Haskell team as a test engineer for 14 months and struggled like hell to understand monads (one of the researchers there came up with using the damn things, but I couldn’t understand it for the life of me). Wasn’t until I stopped looking at it through their academic lenses and had to simply deal with the repetitive errors of several chained functions that I understood it.
fiddlerwoaroof 5y ago
Yeah, the interesting thing is that lots of people vaguely know when they have to use flatMap instead of map and still say things like “monads are too hard”. You can go pretty far by “tricking” people into writing monadic code that works correctly without ever going through the bewildering problem of justifying monads in the abstract.
lvncelot 5y ago
Yes, and I think Haskell monads are somewhat of an outlier in the way they're usually tackled. It's almost as interesting to learn exactly why Javascript promises are not monads, but you won't find any tutorials about Javascript promises that start this way, you just learn how to use promises.
- eyelidlessness 5y ago
  Why are JS Promises not monads? Sincere question.
  - pharmakom 5y ago
    Promise<Promise<T>> is collapsed to Promise<T> automatically, which violates monad laws.
    - eyelidlessness 5y ago
      What’s interesting is this seems to say the exact opposite of what the other direct response says. But I also don’t think this is exactly true. Promise.resolve( Promise.resolve('foo') ) At runtime is Promise<Promise<string>>. It only collapses when chained to then (or await’ed), just as in the sibling comment’s flatMap example.
  - goto11 5y ago
    Monads are a particular pattern for function chaining. In OO terminology it is more like an interface than an object, so I would prefer to say that an object support a monad pattern rather than an object is a monad. JS promises also supports chaining, but not in the same way as the monad pattern. The Array.flatMap() method implements the monad pattern. The signature (in pseudo-typescript notation) would be: Array<T>.flatMap(T => Array<T>): Array<T> I.e the argument is a higher order function which return the same type, and the function also return the same type. This gives unique flexibility in chaining functions, because this: [1, 2, 3].flatMap(x => [x + 1]).flatMap(x => x < 4 ? [x] : []) has the same result as this: [1, 2, 3].flatMap(x => [x + 1].flatMap(x => x < 4 ? [x] : [])) So the functions can be chained or nested, arbitrarily, without affecting the result. The above is equivalent to: [1,2,3].map(x => x + 1).filter(x => x < 4) Which also use method chaining, but not in the same flexible way - you cannot change the chaining to nesting and still get the same result. So not every form of method chaining conform to the monad pattern. (For better or worse - map/filter is clearly easier to read and write, just not as composable.) Note that the definition of monad says nothing about what the semantics of the chaining method (flatMap() in this case) actually is. It only defines the rules for how they can be chained. Generalized, the signature is: Foo<T>.bind(T => Foo<T>): Foo<T> (The method can be called anything, as long as it support the pattern. Traditionally it is called "bind".) As far as I know, promises does not support a similar interface.

bradrn 5y ago

Completely agreed. The only way to learn about monads is to (a) see them being used in examples and (b) use them yourself — exactly like every other concept in programming. Just seeing an abstract explanation is not nearly enough.

exdsq 5y ago
Worked on a Haskell team as a test engineer for 14 months and struggled like hell to understand monads (one of the researchers there came up with using the damn things, but I couldn’t understand it for the life of me). Wasn’t until I stopped looking at it through their academic lenses and had to simply deal with the repetitive errors of several chained functions that I understood it.

fiddlerwoaroof 5y ago

Yeah, the interesting thing is that lots of people vaguely know when they have to use flatMap instead of map and still say things like “monads are too hard”. You can go pretty far by “tricking” people into writing monadic code that works correctly without ever going through the bewildering problem of justifying monads in the abstract.

lvncelot 5y ago

Yes, and I think Haskell monads are somewhat of an outlier in the way they're usually tackled. It's almost as interesting to learn exactly why Javascript promises are not monads, but you won't find any tutorials about Javascript promises that start this way, you just learn how to use promises.

eyelidlessness 5y ago
Why are JS Promises not monads? Sincere question.
- pharmakom 5y ago
  Promise<Promise<T>> is collapsed to Promise<T> automatically, which violates monad laws.
  - eyelidlessness 5y ago
    What’s interesting is this seems to say the exact opposite of what the other direct response says. But I also don’t think this is exactly true. Promise.resolve( Promise.resolve('foo') ) At runtime is Promise<Promise<string>>. It only collapses when chained to then (or await’ed), just as in the sibling comment’s flatMap example.
- goto11 5y ago
  Monads are a particular pattern for function chaining. In OO terminology it is more like an interface than an object, so I would prefer to say that an object support a monad pattern rather than an object is a monad. JS promises also supports chaining, but not in the same way as the monad pattern. The Array.flatMap() method implements the monad pattern. The signature (in pseudo-typescript notation) would be: Array<T>.flatMap(T => Array<T>): Array<T> I.e the argument is a higher order function which return the same type, and the function also return the same type. This gives unique flexibility in chaining functions, because this: [1, 2, 3].flatMap(x => [x + 1]).flatMap(x => x < 4 ? [x] : []) has the same result as this: [1, 2, 3].flatMap(x => [x + 1].flatMap(x => x < 4 ? [x] : [])) So the functions can be chained or nested, arbitrarily, without affecting the result. The above is equivalent to: [1,2,3].map(x => x + 1).filter(x => x < 4) Which also use method chaining, but not in the same flexible way - you cannot change the chaining to nesting and still get the same result. So not every form of method chaining conform to the monad pattern. (For better or worse - map/filter is clearly easier to read and write, just not as composable.) Note that the definition of monad says nothing about what the semantics of the chaining method (flatMap() in this case) actually is. It only defines the rules for how they can be chained. Generalized, the signature is: Foo<T>.bind(T => Foo<T>): Foo<T> (The method can be called anything, as long as it support the pattern. Traditionally it is called "bind".) As far as I know, promises does not support a similar interface.