4 ms·

This: images <- get "http://example.com/images.json" is objectively easier to reason about than: var images; get("http://example.com/images.json"

This: images <- get "http://example.com/images.json" is objectively easier to reason about than: var images; get("http://example.com/images.json", (err, resp) => if err throw err; images = resp; even though the former might be internally implemented as the latter. In addition, the former doesn't give the programmer the 'opportunity' to cause a race-condition, and encapsulates the failure entirely for you (automatically and defaultly); If `images` ends up erroring, and you use it again, then it'll short-circuit without crash, very similar to `then()`.

zak_mc_kracken 12y ago
It's mostly easier to read because it no longer deals with error cases. All code becomes easier to read if you ignore errors. I can make my code arbitrarily short if it doesn't have to be correct.
- chrisdotcode 12y ago
  That's the magic of monads: the errors are all handled for you (in an encapsulated, lossless way), and you can deal with them (if you choose) at the end of the chain, just the same as promises (because promises are a monad).
  - zak_mc_kracken 12y ago
    The same can be said of exceptions. However, my comment above had nothing to do with how you handle errors, it was about the unsoundness of comparing code that handles errors to code that doesn't.
    - chrisdotcode 12y ago
      Right - What I'm saying is that the above former code does handle the error, in the exact same way as the latter code. For clarification, the error is handled implicitly (but you'd know what kind of error it was due to the type signature), but you can always handle it in manner you choose to at any point.
    - tel 12y ago
      It's not really the same as exceptions in a typed language because it's forced to be delimited. Even in Javascript you'll have to do a little ceremony to "escape" the golden path driven by the monad, though you'll have many ways to take short-cuts and forget details.

zak_mc_kracken 12y ago

It's mostly easier to read because it no longer deals with error cases. All code becomes easier to read if you ignore errors. I can make my code arbitrarily short if it doesn't have to be correct.

chrisdotcode 12y ago
That's the magic of monads: the errors are all handled for you (in an encapsulated, lossless way), and you can deal with them (if you choose) at the end of the chain, just the same as promises (because promises are a monad).
- zak_mc_kracken 12y ago
  The same can be said of exceptions. However, my comment above had nothing to do with how you handle errors, it was about the unsoundness of comparing code that handles errors to code that doesn't.
  - chrisdotcode 12y ago
    Right - What I'm saying is that the above former code does handle the error, in the exact same way as the latter code. For clarification, the error is handled implicitly (but you'd know what kind of error it was due to the type signature), but you can always handle it in manner you choose to at any point.
  - tel 12y ago
    It's not really the same as exceptions in a typed language because it's forced to be delimited. Even in Javascript you'll have to do a little ceremony to "escape" the golden path driven by the monad, though you'll have many ways to take short-cuts and forget details.