Callbacks as our Generation's Goto Statement
tirania.org
Callbacks as our Generation's Goto Statement
1–10 of 287 posts
Re: Callbacks as our Generation's Goto Statement
#2I was pleasantly suprised that catoverflow is an actual site.
Re: Callbacks as our Generation's Goto Statement
#3Holy Baader-Meinhof, just today, in frustration, I wrote something like Haskell's sequence_ for ContT, in Javascript:
Re: Callbacks as our Generation's Goto Statement
#4This is what continuations are for.
Re: Callbacks as our Generation's Goto Statement
#5I agree, although I think callbacks are more like COME FROM than goto. You see a function being passed somewhere as a callback, and you know the block is going to execute at some point, but most of the time you have no idea what the codepath that calls you back looks like.
There's nothing more frustrating than trying to debug why a callback isn't being called. Who calls it? How do I set a breakpoint somewhere to see why it isn't being called? etc.
The one thing that is still missing from await and other green thread approaches is cheap global contexts. Isolating every different green thread so they can't implicitly share state is the obvious next step.
Re: Callbacks as our Generation's Goto Statement
#6This is what continuations are for.
Continuations don't help with the problem that the visual structure of callback-oriented programs doesn't reflect the order of execution. As a heavy JS programmer, that's the most compelling point for me in this post.
Re: Callbacks as our Generation's Goto Statement
#7"I have just delegated the bookkeeping to the compiler."
That's not obviously a good thing. Debugging the compiler (or just figuring out why it did something, even if correct) is far more difficult than debugging application code. Given the choice between implementing behavior with application code (or a library function) or adding semantics to the language, I prefer the former because it's much easier to reason about code written in a simple language than to memorize the semantics of a complex language.
[edited to replace sarcasm]
Re: Callbacks as our Generation's Goto Statement
#8There is some creative use of C# async/await in this blogpost:
http://praeclarum.org/post/45277337108/await-in-the-land-of-...
Basically, the author implements a “first time walkthrough” kind of interface a-la iWork very declaratively by using async:
async Task ShowTheUserHowToSearch ()
{
await Tutorial.EnterText (searchField, minLength: 3);
await Tutorial.Tap (searchButton);
await Tutorial.Congratulate ("Now you know how to search.");
}Re: Callbacks as our Generation's Goto Statement
#9I agree, although I think callbacks are more like COME FROM than goto. You see a function being passed somewhere as a callback, and you know the block is going to execute at some point, but most of the time you have no idea what the codepath that calls you back looks like. There's nothing more frustrating than trying to debug why a callback isn't being called. Who calls it? How do I set a breakpoint somewhere to see…
Have you looked at the Erlang model? Each Erlang process (green thread) only gets the arguments initially passed in and whatever else it asks for from other running processes. The only shared state is long-running processes created for the purpose of explicitly sharing state.
Re: Callbacks as our Generation's Goto Statement
#10Callbacks are basically COME FROM, epecially on a platform like a cell phone where you at least in theory have limited processing resources ($40 android phones need apps, too!). They are the devil.