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.
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.