Callbacks as our Generation's Goto Statement (tirania.org)

Why do you as an American feel the need to invoke some dead german left-wing militants in a pseudo-religious phrase that's meaningless except maybe for shock value? This seems highly inapproriate for any website and even more so on HN.

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.

Given that your handle has "racket" in it, I'll assume that you're a call/cc kinda guy.

Even if you're not, others may enjoy this argument against call/cc by Oleg:

http://okmij.org/ftp/continuations/against-callcc.html

Delimited continuations are a huge improvement over undelimited ones, but still, by themselves, any kind of continuations feel like (to me) the GOTOs of functional programming.

More recently, people are doing work with "effect handlers". See Eff & it's research papers, for example:

http://math.andrej.com/eff/

This model is safer, faster, easier, and more composable than general purpose undelimited continuations.

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.

PLEASE. There's nothing wrong with COMEFROM.

This is a nonsensical comment, and I voted it down. The same point can be made about any time languages got a level higher. This kind of rejection of powerful in favor of complex-but-familiar is precisely what Bret Vector warns against in the Future of Programming talk[1].

If anything, `await` makes debugging easier because you don't have to untangle callbacks and jump back and forth. You're not supposed to “debug the compiler” because, well, you know, there are test suites and everything.

Yes, this is something that takes getting used to. Just like `for` loops, functions, classes, futures, first class functions, actors and many other useful concepts and their implementations.

As for your edit, I still can't agree with you.

You're saying:

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

The point of `async` is making the semantics more obvious. Is it much easier to reason about Assembler than C? I say it's not. Would it be for somebody with years of experience in ASM and none in C? Yes it would.

I think it just comes down to that. Callbacks seem simpler to you not because they are simpler (try explaining them to someone just learning the language, and you'll see what I mean), but because you got used to them. Even so, error handling and explicit thread synchronization make maintaining callback-ridden code painful. I think setting `Busy` to `false` in `finally` block is a great example (in the blog post). You just can't do that with nested callbacks—they are not that expressive.

Async allows you to think in structure (`for`, `if`, `while`, etc) about time, that's why it's powerful.

[1]: http://vimeo.com/71278954

    busy = true;
    series([
        function (callback) {
             // step 1, invoke callback();
        },
        function (callback) {
            // step 2, invoke callback();
        },
        function (callback) {
            // step 3, invoke callback();
        }
    ],
    function (err) {
            // finally goes here
            busy = false;
            if (err)
                // ...
    });

While that can be true, I feel like the author inadvertently overstated the amount of work that the compiler is doing here. This is really more of a case of syntactic sugar and not heavy-duty code reordering.

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.

> Callbacks are basically COME FROM

No, they aren't even similar to COME FROM. COME FROM is "upon reaching label X, jump to this point". Callbacks have less in common with COME FROM than with GOTO, and less in common with GOTO than with normal procedure/function invocation.

> epecially on a platform like a cell phone where you at least in theory have limited processing resources

Platform is completely orthogonal to the relation between callbacks and other programming constructs.

Iced Coffeescript is brilliant! I think it is the closest you can get right now to sane development with callback-oriented code in Javascript.

Unfortunately it doens't solve the exception problem yet. Exceptions passed to callbacks (as `(err, value)`) are not thrown. So instead of try/catch there will be lots of `return cb(err) if err` in your code.

This sounds sweet. In my book, C# designers have a history of striking a good balance between simplicity and flexibility. This however always leaves me eager to look at Haskell/ClojureScript/other languages where concepts that C# borrowed and simplified are taken to the full (such as monads, iterators, CSP, etc).

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)
  <-ci

Windows 3.0 had it before Windows 3.1.

First: code that performs simple sequential steps should look simple. With callbacks, it always ends up looking complicated.

Second: refactorability in callback oriented code is a lot worse than linear code. Even refactoring code with a single callback can be annoying. Async code with callbacks that looks and feels like imperative synchronous code is an enormous gain.

I can't comment on futures in c++11, but async/await is more like promises + coroutines, rather than just promises (as defined by Promises/A+)

std::async uses threads (if used with std::launch::async) whereas C# await uses coroutines. You can use Boost.Coroutine to implement something similar in C++ as that project has done: https://github.com/vmilea/CppAwait

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

Await has a potential of simplifying the structure a lot, because it befriends asynchronous operations with control flow.

>And finally, "await" is only applicable when a single callback gets called once at the end. If you're passing a callback that gets used repeatedly (a sorting function, for example), then normal-style callbacks are still necessary, and not harmful at all.

Indeed, await is only for the cases when we abuse functions (because we don't know what we'll call, and we have to bend our minds). Passing the sorting comparator is the primary use of first-class functions.

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

If you like icedcoffeescript, take a look at this:

https://github.com/bjouhier/galaxy

Essentially await/async using Harmony Generators.

What this suggests is that "await" isn't like all structured programming, it's like one control construct. The history of structured programming is the development of more constructs as people realised that they had a goto pattern that kept popping up in their code, so they named it and thereby got a cognitively-higher-level program. Long after Dijkstra's essay, we could still occasionally find new places where goto was really the best way to do it: for instance, if you wanted to "break" out of multiple loops at once. So someone invented named break (likewise continue), and removed yet another use of the unconstrained goto in favour of a more constrained, structured construct.

Taking the OP's premise at face value, then, if callbacks are like goto, then await takes away one place where they were needed and replaces them with something more structured and safer---and this doesn't at all negate the possibility that there are other constructs yet to be invented that would continue that process.

I was initially very skeptical at first too. Then I noticed that the positioning of the "Busy = false" statements had been reduced to a structured form exactly as if we had started with an unstructured GOTO or multiple exit point control flow.

As a C++ guy, I don't like his "Busy = false" system to begin with. It would seem much better (to me) if he used a non-copyable object to represent the outstanding activity. Such an object could naturally reset the "Busy" flag in its destructor. But usually there's a better scheme than using a simple Boolean flag to represent a "busy" state anyway. (How is clearing the flag going to release the next guy waiting for the resource?)

So while I'm still a bit skeptical of drawing conclusions from this, I readily admit it's not so off-the-wall as I'd originally thought.

for/while are themselves syntactic sugar around goto. You can in fact write them as macros or even functions (using setjmp/longjmp) in C. However, the abstraction in that case will leak - you'll need to put your label manually where the loop needs to go, you'll still need to know you're using goto and how it works and you'll need to keep in mind the exact code that's generated by the macro, or you will get bit by it. Structured looping constructs also don't change the flow in your program and even force another level of indentation, but they allow you to think about it using higher-level building blocks being sure that those blocks always work properly, i.e. they won't break because you have a typo in some conceptually far away line.

Callbacks really are just like goto. I've seen really awful callback code where you have callbacks that create other callbacks which are passed to callback managers which are themselves finite state automatons and call one of the callbacks based on a return value from another. It's the most horrifying spaghetti code you can think of. It's practically fractal - spaghetti within spaghetti that influence the top layer in an untraceable manner.

While everyone can write spaghetti in any language, few can write good code when given just goto or just lambda. In some cases it's even impossible.

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.

> I don't think the comparison between callbacks and goto is valid.

What is the largest code base you have worked on that used events + callbacks extensively? I worked on a 250,000 lines-of-code Java trading system, and understanding the way the code flow worked from the central event dispatch loop to handler functions, and back to the event dispatch loop took me MONTHS and seriously spoiled the quality of my life (considering how much many hours we spend at work).

Have you used alternative paradigms like Functional Reactive Programming, Promises, etc;? Maybe you don't realize how awesome the alternative is?

If await isn't changing the way you structure your code -- and letting your code robustly handle things that it couldn't handle with callbacks -- I think you're doing it wrong.

There's nothing inherently harmful about goto either, and people who think that just having it around is death, seriously don't understand the machines they're programming, and how we implement these magical control structures they love so much. (hint: we use goto)

I don't feel any respect for the article because it's written on the premise that goto is bad, and that it is anything like a callback.

Callbacks have been, and will continue to be an incredibly useful way to handle events.

Scala has both Futures and Promises which are inherently much nicer than that async call. That's what happens when you allow things to compose. Glad c# gets something.

That's a smooth point! As you probably know, async code is translated by C# compiler to a state machine[1].

[1]: http://stackoverflow.com/a/4047607/458193

How do you do this with callbacks?

    foreach (var player in players) {
        while (true) {
           var name = await Ask("What's your name");
           if (IsValidName(name)) {
               player.name = name;
               break;
           }
        }
    }

Assuming `Ask` is an asynchronous operation and must not block the UI thread.

Note that second player is only asked after the first player has given a valid name.

(And the code structure reflects that :-)

My point is of course it's doable with callbacks, but I spent more time indenting this code than writing it, and I darn well know I'm not smart enough to spell out the correct callback-style code in a comment field on Hacker News. And if I suddenly had to add error handling...

  for player in players
	get_name_for = (player) ->
		ask "what's your name?", (response) ->
			if is_valid_name response
				player.name = response
			else get_name_for player
	get_name_for player

  get_player_name = (player, next) ->
    ask "what's your name?", (response) ->
        if is_valid_name response
             player.name = response
             next!
    else get_player_name player, next

  get_player_names = ([player,...players]) ->
    get_player_name player, ->
    	if players.length > 0
            get_player_names players

  get_player_names players

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

  (function(players) {
    var cur_idx = 0;
    function cb(name, err) {
      // just kidding, not going to handle errors!
      if (IsValidName(name)) {
        players[cur_idx].name = name;
        cur_idx++;
      }
      if (cur_idx < players.length) {
        Ask("What's your name", cb);
      }
    }
    Ask("What's your name", cb);
  })(players);

    async.eachSeries players, ask, ->
       # Well that was easy enough...
       printRoster(players)

    var playersAsked = 0;
    var askNextPlayerHisName = function(done){
        if (playersAsked === players.length) done();

        Ask("What's your name?", function(name){
            if (IsValidName(name)){
                players[playersAsked].name = name;
                playersAsked++;
            }
            askNextPlayerHisName(done);   
        });
    };
    askNextPlayerHisName(function(){/*...*/});

  function makeAskPlayer(i) {
    return function askPlayerHisName() {
      console.log("askPlayerHisName: " + i);
      Ask("What's your name?", function(name) {
        if (isValidName(name)) { players[i].name = name; }
        else { return (makeAskPlayer(i))(); }   
        // name was valid, get next one
        if (i < players.length-1) (makeAskPlayer(i+1))();
      });
    };
  }
  (makeAskPlayer(0))();

  if not song.artist
    @getArtist song.id, (err, artist) =>
      song.artist = artist
      @save song
      @addToCatalog song
      #...
  else
    @save song
    @addToCatalog song
    #...

  async.eachSeries(
      players,
      function(player, playercb) {
	  var valid = false;
	  async.whilst(
	      function() { return !valid; },
	      function(wcb) {
  		  Ask("What's your name", function(name) {
		      if( IsValidName(name) ) {
			  player.name = name;
			  valid = true;
		      }
		      wcb();
		  });
	      },
	      playercb);
      },
      function() { /* done */ }
  );

  function getAllNames(players, callback){
		function getPlayer(i, players, callback){
		 	Ask("What's your name", function(name){
				if(isValidName(name)){
					players[i++].name = name;
				}
				if(i == players.length){
					callback(players);
				} else {
					getPlayer(i, players, callback);
				}
		 	});
		}
		getPlayer(0, players, callback)
	}

  async.eachSeries(players, askName, function (err) {});

  // this is someplace it should go
  function askName(player, callback) {
    Ask("What's your name", function (err, name) {
      if (err) { return callback(err); }
  
      if (IsValidName(name)) {
        player.name = name;
        callback(null);
      } else {
        askName(player, callback);
      }
    });
  }

    function askPlayers(players, fn) {
      if (!players.length) return fn();

      var player = players[0];

      ask("What's your name", function(name) {
        if (isValidName(name)) {
          player.name = name;
          players.shift();
        }

        askPlayers(players, fn);
      });
    }

Promises were removed from node core a long time ago, and remained unpopular until very recently. They are making a comeback due to lobbying in standards committees, forward-compatibility with ES6 generators, and the jQuery effect.

It is a convention, often used to differentiate blocking and asynchronous methods in the APIs (e.g. `Read` and `ReadAsync`, etc). You're not required to use it, but it is useful whenever there is a chance of confusion.

As for the timeouts, it would be strange to bake this into a language (different platforms may support different timers, at the very least).

Instead, you use library for this[1]:

    int timeout = 1000;
    var task = SomeOperationAsync();
    if (await Task.WhenAny(task, Task.Delay(timeout)) == task) {
        // task completed within timeout
    } else { 
        // timeout logic
    }

Instead of awaiting on a task, you await on `WhenAny` combinator.

[1]: http://stackoverflow.com/a/11191070/458193

The Async suffix is here to differentiate with the synchronous version of an existing method returning T, the asynchronous return a Task<T>. 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
  }