3 ms·

My hero in this regard is Erik Meijer who went to Microsoft purposefully to bring Haskell concepts to .NET as he recounts in "Confessions of a Used language Sal

My hero in this regard is Erik Meijer who went to Microsoft purposefully to bring Haskell concepts to .NET as he recounts in "Confessions of a Used language Salesman: Getting the Masses Hooked on Haskell" (2010) [1] He put async/await in Dart after working on it in C#, a feature I really appreciate. From my limited understanding and I hope someone will correct me, it is a continuation monad. Everything I know about monads comes from "Explain Monads Like I'm five" by Theofanis Despoudis [2] "After failing to sell solving real world problems to the Haskell community, as well as failing to sell Haskell to the real world, I started to wonder whether pushing for pure functional languages was actually the right strategy. Maybe I thought, I should sell my soul to the most popular programming paradigm, objects, and to the company that has the biggest market share, Microsoft... My main reason to join Microsoft as the company to infuse mainstream programming languages with monads and other functional programming features was that I believed the quickest road to success would be to work on adding support for exotic language features to the new Common Language Runtime..." [1] http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.72.868&rep=rep1&type=pdf http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.72.... [2] https://dev.to/theodesp/explain-monads-like-im-five https://dev.to/theodesp/explain-monads-like-im-five

lmm 6y ago
> From my limited understanding and I hope someone will correct me, it is a continuation monad. Everything I know about monads comes from "Explain Monads Like I'm five" by Theofanis Despoudis [2] Futures/promises do form a monad. async/await is not a monad since async and await are not values, functions, or anything really. If they're implemented on top of futures/promises then async/await are like a hamstrung version of do notation that only works for one particular monad. Also async/await is not really full continuations, it's a very restricted subset of continuations (which is good, full continuations are incomprehensible).
- boxmonster 6y ago
  Thank you. I was including futures promises in my mention of async/await because that's how I use them mostly. I couldn't remember where I got some confirmation about my understanding, but since found it in my bookmarks. It seems to me that Haskell programmers want to abstract away the machine and this makes me wonder how well this works with practical concerns of controlling the computer to make it work. I look forward to learning more: "async/await is just the do-notation of the Promise monad" https://gist.github.com/MaiaVictor/bc0c02b6d1fbc7e3dbae838fb1376c80 https://gist.github.com/MaiaVictor/bc0c02b6d1fbc7e3dbae838fb...
  - lmm 6y ago
    Haskell programmers generally believe in making it clear what the code means and letting the compiler/runtime figure out the details of how to execute it. A perfect programmer with infinite time could almost certainly get more optimal behaviour by specifying all the details; on the other hand, a language that expects the programmer to specify all the details gives them plenty of opportunity to get those details wrong, or for their choices to become outdated. In my experience Haskell significantly outperforms C++ on real-world business problems with realistic development effort (as opposed to carefully tuned microbenchmarks). I do think laziness was a mistake (to the point that one of the biggest industrial deployments uses a strict variant instead). I've spent most of my career doing work in Scala that's very much real-world, so as far as I'm concerned all the people talking about these things being academic or overly abstract are talking crap - I use this stuff every day, and whenever I've tried to take a shortcut (e.g. define a slightly law-breaking monad instance, abuse some mutable state somewhere) I've come to regret it later.

lmm 6y ago

> From my limited understanding and I hope someone will correct me, it is a continuation monad. Everything I know about monads comes from "Explain Monads Like I'm five" by Theofanis Despoudis [2] Futures/promises do form a monad. async/await is not a monad since async and await are not values, functions, or anything really. If they're implemented on top of futures/promises then async/await are like a hamstrung version of do notation that only works for one particular monad. Also async/await is not really full continuations, it's a very restricted subset of continuations (which is good, full continuations are incomprehensible).

boxmonster 6y ago
Thank you. I was including futures promises in my mention of async/await because that's how I use them mostly. I couldn't remember where I got some confirmation about my understanding, but since found it in my bookmarks. It seems to me that Haskell programmers want to abstract away the machine and this makes me wonder how well this works with practical concerns of controlling the computer to make it work. I look forward to learning more: "async/await is just the do-notation of the Promise monad" https://gist.github.com/MaiaVictor/bc0c02b6d1fbc7e3dbae838fb1376c80 https://gist.github.com/MaiaVictor/bc0c02b6d1fbc7e3dbae838fb...
- lmm 6y ago
  Haskell programmers generally believe in making it clear what the code means and letting the compiler/runtime figure out the details of how to execute it. A perfect programmer with infinite time could almost certainly get more optimal behaviour by specifying all the details; on the other hand, a language that expects the programmer to specify all the details gives them plenty of opportunity to get those details wrong, or for their choices to become outdated. In my experience Haskell significantly outperforms C++ on real-world business problems with realistic development effort (as opposed to carefully tuned microbenchmarks). I do think laziness was a mistake (to the point that one of the biggest industrial deployments uses a strict variant instead). I've spent most of my career doing work in Scala that's very much real-world, so as far as I'm concerned all the people talking about these things being academic or overly abstract are talking crap - I use this stuff every day, and whenever I've tried to take a shortcut (e.g. define a slightly law-breaking monad instance, abuse some mutable state somewhere) I've come to regret it later.