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

151–160 of 287 posts

Re: Callbacks as our Generation's Goto Statement

#151

Post by rogerbinns »

hokkos wrote: post #98
rogerbinns wrote: post #50

I noticed that most of the methods awaited on had an Async suffix in their name. Is that some sort of modern hungarian notation, and is it even necessary? It also looks like you can't pass timeouts to await.

The Async suffix is here to differentiate with the synchronous version of an existing method returning T, the asynchronous return a Task . With a Task you can do : int timeout = 1000; var task = SomeOperationAsync(); if (await Task.WhenAny(task, Task.Delay(timeout)) == task) { // task completed within timeout } else { // timeout logic }

According to the Microsoft doc[1] it is convention for async to return a Task but not a requirement. Since the return type of Task tells you a method is expected to be used asynchronously, also encoding that in the name seems somewhat redundant. I guess you have to use a different name because of static typing so Async is as good a suffix as any.

[1] http://msdn.microsoft.com/en-us/library/vstudio/hh156528.asp...

Re: Callbacks as our Generation's Goto Statement

#152

Post by adamconroy »

zowch wrote: post #138
adamconroy wrote: post #93

Why do people insist on analysing things using analogies? Analogies are useful for explaining a concept that might not be obvious. Saying callbacks are like gotos, gotos are bad, therefore callbacks are bad is ridiculous. And he gives some sample code where the 'problem' is nothing to do with callbacks, its just nested lambdas. In fact I find that code quite easy to read, and would be very interested in seeing the sa…

I'm confused as to why you think the code presented in the blog post isn't an example of 'the same functionality implemented some other way'. The await code is almost undeniably more straightforward and the exceptional cases more obvious to handle. He also doesn't seem to be making a weird logical leap the way you claim he is. He's not really using an analogy. He's saying callbacks are bad the same way goto is bad, i…

I'm not saying the await syntax isn't useful or a better way to implement that problem. The title and opening of the article is comparing callbacks with gotos. It would be logical if he titled the article "C# Await syntax trumps callbacks when multiple callbacks need to be synchronised".

Any syntax can be used to create spaghetti code. Callbacks only become spaghetti like when nested / chained / abused. I've written hundreds of API methods using callbacks that I believe are very clean. I've recently written a large API which makes async service calls that follows this pattern :

void GetInvoiceHistory(int? customerId, Action> callback, Action exceptionCallback);

The consumer of this API does not need await, there is no need to nest callbacks, there is no need for try/catch and it is very clean to work with. So IMHO, stating that callbacks are this generation's gotos is a pile of shit.

Re: Callbacks as our Generation's Goto Statement

#154

Post by MichaelMoser123 »

danabramov wrote: post #8

There 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 kno…

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 variables according to search option.

So, like any mechanism, this way of structuring code has its limits. If an event can happen at any stage of the flow, then this still has to be handled by a callback, otherwise you would have to check for this kind of event after each await clause.

Re: Callbacks as our Generation's Goto Statement

#155

Post by singlow »

danabramov wrote: post #70
singlow wrote: post #67

Earlier quoted context omitted.

Maybe like this? players.forEach(function() { 'use strict'; var player = this; var name = Ask("What's your name?, function(name) { if (isValidName(name) { player.name = name; } }); });

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.

Re: Callbacks as our Generation's Goto Statement

#156

Post by outside1234 »

peterashford wrote: post #123
sker wrote: post #30

Earlier quoted context omitted.

The C# designers outdid themselves this time. I'm surprised they managed to made this feature so simple and succinct, especially for an "enterprise" language. Those two little words (async/await) seem like something I would expect from a language like Python or Ruby. Had it been Java, it would be called AsynchronousBureaucraticProccessDispatcherFactoryFactoryFactory.

You know, this kind of BS about Java is a little tiresome.

sometimes the truth hurts

Re: Callbacks as our Generation's Goto Statement

#157

Post by swannodette »

klibertp wrote: post #65
danabramov wrote: post #41

Earlier quoted context omitted.

By the way, how do F#'s async workflow compare to ClojureScript? Are they equally powerful?

In F# workflows are just a syntactic sugar for monads, much like Haskell 'do' notation. You can get continuation monad (workflow) in F# easily. I don't know what ClojureScript uses, but it doesn't seem very likely that it has more powerful mechanism :)

As Brandon alludes below monadic designs generally have allocation overheads, this is why C# uses state machines. So while they may be equivalent in some abstract sense of "power" one ends up being more efficient in practice.

Re: Callbacks as our Generation's Goto Statement

#160

Post by MichaelGG »

brandonbloom wrote: post #73
MichaelGG wrote: post #36

Earlier quoted context omitted.

F# implemented this many years before (6 years ago), and as a library , just by providing the proper language feature, workflows, and a default async implementation. In comparison, C# adds special compiler keywords for one specific example, just like they did with LINQ. That seems rather ugly IMO. Providing building blocks and letting libraries fill things in is a lot nicer. This is more of a "C#'s finally catching u…

I don't think it's fair to characterize this as "catching up". Both F# and C# are developed by an overlapping group of people at Microsoft. And, until recently, the bulk of Haskell's GHC was done by SPJ in a closely collaborating group in Microsoft Research. The correct characterization is to view this as a pipeline from a research language, to a specialists' language, to a common man's language. Six years isn't real…

C# operates entirely differently, I understand. The IDE work is massive and necessary. Having said that, a lot of this stuff is "catching up" or implementing stuff from the 70s. To be clear, it's not like type inference or closures were invented with Haskell, F#, or C#. Stuff like that is pretty well-known PL stuff, isn't it?

People would be upset if C# didn't have for loops; why aren't they upset the type inference is nearly useless?

Post reply on HN