3 ms·

There are two responses here. The first is that in any language which has any sort of threading model at all, sequential code in multiple threads obviates the n

by ezyang 10y ago

There are two responses here. The first is that in any language which has any sort of threading model at all, sequential code in multiple threads obviates the need for callbacks. If you block, fine; it's just a single thread, it's not obstructing the handling of other threads. Why don't Python and JavaScript have multithreading? Well, because programming with unrestricted concurrency and mutable state is really difficult. But there are ways to solve this problem, Haskell's purity being one among several. The second is that do-notation is distinct from the IO monad. Even if Haskell didn't have green threads in the runtime, I could still write an async/callback library that looked just as natural as sequential code. Why? It has nothing to do with the IO monad: it has to do with the fact that "do x <- e; m" desugars to, in JavaScript notation, bind(e, function(x) { m }); it's been "callbackified automatically".

quotemstr 10y ago
> could still write an async/callback library that looked just as natural as sequential code You can do that in any language with AST transforms powerful enough to transform code into CPS. That functions are "automatically callbackified" is an implementation detail and not one particularly germane to high-level code.
- rtpg 10y ago
  well that's kind of the point isn't it? That Python doesn't offer this, and that Haskell is one of the few production-ready tools that offer this in a clean way?
  - quotemstr 10y ago
    Who cares how it's implemented? Python lets you write straight-line code that does more than one IO-bound thing at a time. So does Haskell. That one is using a CPS transform under the hood and the other stack-switching via OS threads is irrelevant.
    - rtpg 10y ago
      it's not exactly the same. Python lets you write straight-line code, but you still have to be explicit about the sync/async nature of each call. You can abstract this away in Haskell, thanks to some interesting tooling around `do` notation. Some people prefer the explicit nature though.

by ezyang 10y ago

quotemstr 10y ago

> could still write an async/callback library that looked just as natural as sequential code You can do that in any language with AST transforms powerful enough to transform code into CPS. That functions are "automatically callbackified" is an implementation detail and not one particularly germane to high-level code.

rtpg 10y ago
well that's kind of the point isn't it? That Python doesn't offer this, and that Haskell is one of the few production-ready tools that offer this in a clean way?
- quotemstr 10y ago
  Who cares how it's implemented? Python lets you write straight-line code that does more than one IO-bound thing at a time. So does Haskell. That one is using a CPS transform under the hood and the other stack-switching via OS threads is irrelevant.
  - rtpg 10y ago
    it's not exactly the same. Python lets you write straight-line code, but you still have to be explicit about the sync/async nature of each call. You can abstract this away in Haskell, thanks to some interesting tooling around `do` notation. Some people prefer the explicit nature though.