Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Callbacks as our Generation's Goto Statement

tirania.org

Post reply on HN
Print view View original

281–287 of 287 posts

Re: Callbacks as our Generation's Goto Statement

#281

Post by ufo »

stcredzero wrote: post #253
kvb wrote: post #134

Earlier quoted context omitted.

I often write synchronous methods that include control flow that nests three deep (say try/finally, if/then/else, and a for loop). Often it's easier to read this code than it would be if everything were split out into separate named methods. Why would the same not be true of asynchronous methods, assuming that the technology was there to enable it (as it is in C#)?

> Often it's easier to read this code than it would be if everything were split out into separate named methods. This might actually be a shortcoming of our code organization/reading tools.

Why should that be the case? Creating all the extra methods is going to create lots of new points of indirection, the new methods are likely to be tightly coupled anyway and breaking the nesting might mean you have to hoist a bunch of variables into an outer scope.

Re: Callbacks as our Generation's Goto Statement

#282

Post by ufo »

rgbrgb wrote: post #6
racketeer wrote: post #4

This 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.

I think he was referring to features like call/cc. They are very similar to C#'s await in that you write regular looking code and the language does the heavy lifting of figuring out what the real continuation is supposed to be.

Re: Callbacks as our Generation's Goto Statement

#283

Post by swiil »

I actually believe that code should be synchronous unless instructed to operate asynchronously - just my .02

Await should not be required - it should be more like...

--

regularWork(); //im waiting till this thing is done

driveHome();// not executed till thing one is done

background orderStatus = orderPizza();

turnOnXbox();

while(orderStatus == 'not ready') {

playXbox();

}

turnOffXbox();

eat();

--

Like I said - just my humble opinion that the code written would become more expressive.

Re: Callbacks as our Generation's Goto Statement

#284

Post by stcredzero »

ufo wrote: post #281
stcredzero wrote: post #253

Earlier quoted context omitted.

> Often it's easier to read this code than it would be if everything were split out into separate named methods. This might actually be a shortcoming of our code organization/reading tools.

Why should that be the case? Creating all the extra methods is going to create lots of new points of indirection, the new methods are likely to be tightly coupled anyway and breaking the nesting might mean you have to hoist a bunch of variables into an outer scope.

Exercise: list all of the implicit assumptions about how code organizing and reading tools have to work from those two sentences.

Re: Callbacks as our Generation's Goto Statement

#285

Post by stcredzero »

anonymous wrote: post #199
sirmarksalot wrote: post #195

Earlier quoted context omitted.

Another example: a lot of old code bases use "goto" for error handling. I'm assuming the Linux kernel still does this. Now we've formalized that behavior into exceptions.

You need C++'s RAII idiom or go's defer syntax to get the same behaviour though. I think try-with-resource in Java also would do the same thing, maybe. Just plainly throwing an exception won't release what you've acquired.

ensure: blocks were how it was done in Smalltalk. You simply had a block of code that was followed by another block of code that the system would ensure the execution of. There was slightly more to it. You had to make sure that whatever ran in that block wouldn't take too long to complete, for example.

Re: Callbacks as our Generation's Goto Statement

#286

Post by MichaelMoser123 »

thallium205 wrote: post #231
MichaelMoser123 wrote: post #154

Earlier quoted context omitted.

What if you have two buttons, search and 'be lucky'? I guess you will have to await for a controller object that wakes up that if either one of the buttons is triggered, and then test what button was pressed. Now what if you have add a search option dialog that can be invoked at any moment? I guess when the 'apply' button of the option dialog got pressed then this is still going to be a callback that sets global vari…

"What if you have two buttons, search and 'be lucky'? I guess you will have to await for a controller object that wakes up that if either one of the buttons is triggered, and then test what button was pressed." http://msdn.microsoft.com/en-us/library/hh194796.aspx

... select or WaitForMultipleObjects in another form

Re: Callbacks as our Generation's Goto Statement

#287

Post by carbocation »

chaosphere2112 wrote: post #92
benhoyt wrote: post #63

Earlier quoted context omitted.

Yeah, C# await/async is cool. But isn't Google Go's approach nicer? Keep standard lib calls blocking as is, and use the "go" statement when you want to run something async? It avoids all the extra DoWhateverAsync() API functions. See http://stackoverflow.com/a/7480033/68707 What's the Go equivalent of "await"? I.e., like the "go" statement but asynchronously wait for the function to return and get its value?

ci := make(chan int) go func(ci)

If you're using `ci` as just a semaphore, you should use a struct, since those use even less memory than an int in go.
Post reply on HN