Good intro to continuations, but just reinforces the reasons I dislike them and wouldn't use them.
Also disagree about "What is asynchronous programming, and why is it so damn awkward?"
It's not awkward in the least. Either you write your code to remember the things you need to remember, or you use something like continuations which will be pretty inefficient and ugly (IMHO).
Continuations can certainly be ugly (under some circumstances), and difficult, too. But there's no reason why this particular implementation of continuations needs to be inefficient—it has a one-to-one mapping with ordinary asynchronous JavaScript, and it generates exactly the code you'd otherwise write by hand.
Overall, I think this is a win for clarity. But I think the author should also transform functions that take a callback argument, and implicitly convert them to continuation style. Perhaps this could by adding the callback parameter automatically and transforming 'return' into a callback invocation?
Regarding transformations of returns, the initial implementation added an anonymous callback argument and converted returns into using it. But that takes the option of using the callback out of the programmer's hands, and is entirely non-obvious for someone calling the function (the number of parameters required is one more than those listed in the function definition)
I plan to write a follow-up shortly that discusses possible approaches of doing this sort of thing, and your suggestion is one of the ideas I'm going to explore. Thanks for reading & commenting :)
I'd like to see an example of nontrivial asynchronous code that isn't at least a little awkward.
continuations may well be inefficient, it depends on the runtime. `defer` does not implement real continuations, so that's largely irrelevant - there is no runtime overhead that you don't already have by writing your own callback functions.
As for ugly, do you refer to the compiled output, or the source code? gcc outputs some pretty ugly assembly code; does it matter?
Comments
Good intro to continuations, but just reinforces the reasons I dislike them and wouldn't use them.
Also disagree about "What is asynchronous programming, and why is it so damn awkward?"
It's not awkward in the least. Either you write your code to remember the things you need to remember, or you use something like continuations which will be pretty inefficient and ugly (IMHO).
Continuations can certainly be ugly (under some circumstances), and difficult, too. But there's no reason why this particular implementation of continuations needs to be inefficient—it has a one-to-one mapping with ordinary asynchronous JavaScript, and it generates exactly the code you'd otherwise write by hand.
Overall, I think this is a win for clarity. But I think the author should also transform functions that take a callback argument, and implicitly convert them to continuation style. Perhaps this could by adding the callback parameter automatically and transforming 'return' into a callback invocation?
async function (x) { return x; } =>
function (x, callback) { callback(x); }
Regarding transformations of returns, the initial implementation added an anonymous callback argument and converted returns into using it. But that takes the option of using the callback out of the programmer's hands, and is entirely non-obvious for someone calling the function (the number of parameters required is one more than those listed in the function definition)
I plan to write a follow-up shortly that discusses possible approaches of doing this sort of thing, and your suggestion is one of the ideas I'm going to explore. Thanks for reading & commenting :)
I'd like to see an example of nontrivial asynchronous code that isn't at least a little awkward.
continuations may well be inefficient, it depends on the runtime. `defer` does not implement real continuations, so that's largely irrelevant - there is no runtime overhead that you don't already have by writing your own callback functions.
As for ugly, do you refer to the compiled output, or the source code? gcc outputs some pretty ugly assembly code; does it matter?
I'm referring to the source code. Also though ugly in terms of "eugh this isn't going to run efficiently. Mem usage will be crappy etc"
I've written a large amount of async code now, both in js and in java. I don't ever feel it's awkward, do you have an example of this awkwardness?