5 ms·
Few nits with this: 1. This seems like an article about Haskell's do-notation, not Monads. The article even decries Promises, which _are_ Monads. 2. "Call you
by rattray 9y ago
Few nits with this:
1. This seems like an article about Haskell's do-notation, not Monads. The article even decries Promises, which _are_ Monads.
2. "Call you language implementor and ask for do-notation today!" isn't very satisfying. I would be curious to read such a proposal for eg; JS, though it would need another name (do-expressions already have a proposal). Meanwhile, it might have been helpful to show how to implement these Monads in a common tongue (eg; JS).
3. The article did not display the bodies (or even type signatures) of the functions at hand. It's unclear to a reader unfamiliar with Haskell whether they are all the same, and what interface they must conform to.
4. The examples listed as "Hell" don't sound like hell to me. They're minor annoyances that I run into occasionally. The code listed as "problematic" isn't blissful to write and doesn't feel elegant, but is universally easy to write and read.
As an aside, it feels like Go and Haskell would be at opposite ends of some spectrum (obvious vs elegant?). In almost any business/production setting, I would choose the former.
- deleted 9y ago[deleted]
- networked 9y ago>do-expressions already have a proposal For those who are curious, it's this one: https://github.com/tc39/proposal-do-expressions https://github.com/tc39/proposal-do-expressions.