Callbacks as our Generation's Goto Statement • Hacker News Board

Re: Callbacks as our Generation's Goto Statement

#41

Post by danabramov » Thu, Aug 15, 2013, 11:03 PM UTC

MichaelGG wrote: post #36

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.

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…

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

Re: Callbacks as our Generation's Goto Statement

#42

Post by hderms » Thu, Aug 15, 2013, 11:04 PM UTC

I love when Node.js advocates try to convince you that promises are as good a concept as anyone would need to handle asynchronous programming

Re: Callbacks as our Generation's Goto Statement

#43

Post by sker » Thu, Aug 15, 2013, 11:04 PM UTC

MichaelGG wrote: post #36

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.

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…

Yes, C# tends to copy F# features in the way of compiler-syntactic-sugar. I wonder if Type Providers will be next. Async/await have been around for a couple of years and I haven't heard of the next big C# feature, other than Roslyn.

Re: Callbacks as our Generation's Goto Statement

#44

Post by hderms » Thu, Aug 15, 2013, 11:04 PM UTC

danabramov wrote: post #39

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…

You're missing the point of `await`. Await does change how your program is structured, unless we're talking about most trivial cases. You can use `await` inside a `for` loop—can you do the same with callbacks without significantly re-structuring your code? What is the “callback analog” of placing something in a `finally` block that executes no matter which callback in a nested chain fails? You'd have to repeat that c…

Very concise reply with solid examples. You've sold me!

Re: Callbacks as our Generation's Goto Statement

#45

Post by danabramov » Thu, Aug 15, 2013, 11:09 PM UTC

sker wrote: post #43

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…

Yes, C# tends to copy F# features in the way of compiler-syntactic-sugar. I wonder if Type Providers will be next. Async/await have been around for a couple of years and I haven't heard of the next big C# feature, other than Roslyn.

They seem to be pretty busy with Roslyn, Anders recently admitted it's taking longer than originally expected. So perhaps we need to give 'em a break. The only thing I heard about C# 6 so far is it's maybe going to have more compact class declarations, a-la F# or TypeScript.

Re: Callbacks as our Generation's Goto Statement

#46

Post by anonymoushn » Thu, Aug 15, 2013, 11:10 PM UTC

dragonwriter wrote: post #38

anonymoushn wrote: post #33

Earlier quoted context omitted.

Actually, they do. C#'s await (and any similar scheme based on ES6 generators) is a feature that can be built using continuations.

So are Java/C#/everything-else exceptions. And, for that matter, pretty much every control flow construct imaginable. OTOH, I think that the big problem with continuations is that it gets very difficult to build efficient implementations of them (and this tends to impact not just efficiency of code that uses continuation, but usually efficiency of any code in a language which supports them), and it is much more effic…

Supporting call/cc and dynamic-wind has a significant performance impact in some languages, even for code that does not use the features.

Supporting coroutine.create+coroutine.clone, shift+reset, or setcontext+getcontext+makecontext+swapcontext seems to have no performance impact on code that does not use the features.

Re: Callbacks as our Generation's Goto Statement

#47

Post by crazygringo » Thu, Aug 15, 2013, 11:11 PM UTC

danabramov wrote: post #39

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…

You're missing the point of `await`. Await does change how your program is structured, unless we're talking about most trivial cases. You can use `await` inside a `for` loop—can you do the same with callbacks without significantly re-structuring your code? What is the “callback analog” of placing something in a `finally` block that executes no matter which callback in a nested chain fails? You'd have to repeat that c…

I'm not disagreeing with you at all.

I guess we're using "structured" in different ways. Libraries like TameJS do wind up creating structures to deal with for loops, in the same way you'd otherwise manually have to deal with. Likewise with exceptions (which I said are the main actual benefit to await, that can't be reproduced in normal callback routines).

You obviously have to write a bunch of "plumbing" code to do with "raw" callbacks, in complicated situations (like loops), which "await" does on its own -- and writing that plumbing is annoying, although there are libraries to help.

My only point is, the fundamental structure of your program, on a conceptual level, is still the same. Everything's still running the same way, in the same order. It's just more concise, with less plumbing of your own, using "await". So the micro structure is different with await, but the high-level structure is no different. You can't "abuse" callbacks in the way you can abuse goto. Maybe I should have made that clearer.

Re: Callbacks as our Generation's Goto Statement

#48

Post by wrl » Thu, Aug 15, 2013, 11:11 PM UTC

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…

Let's not forget that "if", "for", "while", "switch", and friends, fundamentally, aren't anything more than syntactic sugar for "goto" either. ;)

Re: Callbacks as our Generation's Goto Statement

#49

Post by [deleted] » Thu, Aug 15, 2013, 11:12 PM UTC

MichaelGG wrote: post #36

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.

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…

[deleted]

Re: Callbacks as our Generation's Goto Statement

#50

Post by rogerbinns » Thu, Aug 15, 2013, 11:13 PM UTC

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.