4 ms·

> Promises and callbacks do not have this property: they force the programmer to make the continuation explicit. This is exactly what I'm complaining about in

by jkrems 12y ago

> Promises and callbacks do not have this property: they force the programmer to make the continuation explicit. This is exactly what I'm complaining about in the gist... :( Generators != coroutines. You can use generators to simulate coroutines - but only if you combine them with either Promises or callbacks (or another async abstraction). Pretending like generators "replace" promises or callbacks doesn't help anybody imo. ES7 async functions are a great example of what happens when you embrace the fact that generators need promises of some sort to act as coroutines. You gain return values of functions - something that kinda got lost when JS started using callbacks: async function getUsername(id) { let user = await getUser(id); return user.name; // returns a Promise<String> }); By pretending that generator-based coroutines "got rid of" callbacks and promises, we are taking a huge step back. Even co is by now embracing the fact that coroutines require more than "just" generators.* (*) Unfortunate only that koa gained traction before co got that memo. Otherwise it might ended up with a saner API than "mutate random properties on this". Maybe even something crazy/revolutionary like "return a response".

nostrademons 12y ago
You certainly don't need promises for generators to act like coroutines. Take a look at how Python 2.5 handles generators; yield is an expression, and then the external interface to a generator is a stream with a send() method you can use to resume the generator. (As another poster pointed out, a stream is a much more precise description of the abstraction than an array - arrays support constant-time random access, while streams are just ordered collections of elements.) I do think that combining futures/promises with generators gives a much cleaner programming model. Take a look at how Python 3.4 handles generators & async programming; here a generator is implicitly a Future, and 'yield from' runs a future to completion, letting you compose coroutines regardless of how many yield points they have. But my point is that these are all programming models, different ways to present the underlying abstraction to programmers. It's silly to talk about "the fact that coroutines require..." or "generators need promises" or "pretending that...", as if there were only one way to do async programming - these are not universal abstractions, they are models to present the underlying scheduler to programmers, and we choose between them based on how convenient they are to programmers.

by jkrems 12y ago

nostrademons 12y ago

You certainly don't need promises for generators to act like coroutines. Take a look at how Python 2.5 handles generators; yield is an expression, and then the external interface to a generator is a stream with a send() method you can use to resume the generator. (As another poster pointed out, a stream is a much more precise description of the abstraction than an array - arrays support constant-time random access, while streams are just ordered collections of elements.) I do think that combining futures/promises with generators gives a much cleaner programming model. Take a look at how Python 3.4 handles generators & async programming; here a generator is implicitly a Future, and 'yield from' runs a future to completion, letting you compose coroutines regardless of how many yield points they have. But my point is that these are all programming models, different ways to present the underlying abstraction to programmers. It's silly to talk about "the fact that coroutines require..." or "generators need promises" or "pretending that...", as if there were only one way to do async programming - these are not universal abstractions, they are models to present the underlying scheduler to programmers, and we choose between them based on how convenient they are to programmers.