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

201–210 of 287 posts

Re: Callbacks as our Generation's Goto Statement

#201

Post by barrkel »

crazygringo wrote: post #31

"Await" is fantastic, and having using it for JavaScript (via TameJS and then IcedCoffeeScript), it makes things a lot easier and clearer. That being said, I don't think the comparison between callbacks and goto is valid. "Goto" allows you to create horrible spaghetti-code programs, and getting rid of it forces you to structure your programs better. "Await", fundamentally, isn't really anything more than syntactic su…

I wrote about this very problem some time ago:

http://blog.barrkel.com/2006/07/fun-with-asynchronous-method...

Await is basically a continuation-passing style transform that puts the continuation in the continue handler of the task. The exception handling is also no more or less syntax sugar than the CPS rewrite - it's an error continuation that needs to be routed by querying the underlying Task's properties.

But the really great thing is that you can finally just thread the async keyword through your call stack to get the CPS effect across multiple method call boundaries, even your case of a sorting function. It's not just applicable for a single callback; the second half, the implementation half, is also implemented, so you're not just limited to using the pattern, but creating new instances easily too.

Re: Callbacks as our Generation's Goto Statement

#202

Post by danabramov »

raverbashing wrote: post #198
ufo wrote: post #164

Earlier quoted context omitted.

But doing things by hand with callbacks is going to have all of those same issues isnt it? If you dont want to infect everything then you basically need to just write synchronous code instead...

The issue I see is that with some libraries you either go 100% async or 100% sync with no middle ground.

This is simply not true. You can use any C# library without using async (code rewriter). You'd still be using Tasks but there is nothing special about them (no compiler magic). They're just futures on which you can schedule continuations.

Re: Callbacks as our Generation's Goto Statement

#203

Post by danabramov »

singlow wrote: post #155
danabramov wrote: post #70

Earlier quoted context omitted.

Same problem like with the sibling post: this will ask two players simultaneously. My example waits for each player to provide a valid name in turn.

Well, if the Ask function should only run once at a time, it should block itself.

Imagine it's an iOS modal prompt. It doesn't block the thread, it sends an event.

Re: Callbacks as our Generation's Goto Statement

#204

Post by danabramov »

scott_s wrote: post #149
captaincrowbar wrote: post #96

Earlier quoted context omitted.

If you're doing everything sequentially anyway, why bother with the awaiting part? As far as I can see your example would be functionally unchanged if you wrote the same code except without the await keyword.

Because it doesn't block the thread. The idea is that this code is executed inside of a thread that, if it blocks, will cause the application to hang. For example, in a GUI or a server. So, if its a thread driving a GUI, and it's blocked on user input, then the entire application interface will be unresponsive until it receives that input.

This. Specifically, I'm thinking about iOS prompts and alerts, they are not blocking.

Re: Callbacks as our Generation's Goto Statement

#205

Post by danabramov »

eonil wrote: post #161

It's right that callback model sucks, and the task model is a way to go. Sadly, many developers when they hear the word "C# async" ... All of these statements are made by people that have yet to study C# async or to grasp what it does. But it's unpleasant to see the author is talking concept of task - lightweight threading, coroutine, or whatever - is like a patent of C# (or F#). And furthermore, treating many develo…

Have you read the article? It's not about tasks per se, it's about a code rewriter.

Re: Callbacks as our Generation's Goto Statement

#206

Post by danabramov »

coreyja wrote: post #124

I think this article misses a main point and that's the fact that all await does it take a function that used to be asynchronous and makes it synchronous. While yes, there are definitely use cases where that is nice, in general I think that if you want to use an await command, why are you making a call that was meant to be async? You are defeating the whole point of async calls. Yes I know a lot of standard libraries…

You misread the article. The compiler allows you to write code in sequential manner but rewrites it into a state machine with callbacks.

Re: Callbacks as our Generation's Goto Statement

#208

Post by danabramov »

marcosdumay wrote: post #146
javert wrote: post #133

I have a basic technical question. I work in C for embedded systems, so I'm a bit "behind the times." How is "await" any different from a regular blocking system call? A regular system call does exactly what is being described: The system call happens, and then when it is finished, execution resumes where it left off. (Yes, this makes the thread block... which is why you have multiple threads. I think the answer will…

I'm not a beliver, so I may be missing something important... As far as I can see, await makes it possible to do things like: - UI Thread starts Thread X to do something slow; - Thread X is processing, in the meantime the user clicks on something that requires X's result; - Only now the UI thread stops, waiting for X. Your program stay responsive, unless it's completely not able to do so. As I said, I still don't thi…

No, you got it wrong. Await never blocks the UI thread.

Instead, the compiler rewrites your sequential code into a state machine. When you await on a task, the compiler turns this into scheduling a continuation. No blocking.

Re: Callbacks as our Generation's Goto Statement

#209

Post by danabramov »

javert wrote: post #133

I have a basic technical question. I work in C for embedded systems, so I'm a bit "behind the times." How is "await" any different from a regular blocking system call? A regular system call does exactly what is being described: The system call happens, and then when it is finished, execution resumes where it left off. (Yes, this makes the thread block... which is why you have multiple threads. I think the answer will…

You never want to block UI thread in a GUI app.
Post reply on HN