Live data from Hacker News

Callbacks as our Generation's Goto Statement

tirania.org

171–180 of 287 posts

Re: Callbacks as our Generation's Goto Statement

#171

I don't understand what the big deal is. Callbacks are OK. They're less cumbersome if the language you're using has smaller function definitions. Callbacks 'get crazy' when you've got more than one I think, and thankfully someone smart has made a library you can use to manage them! https://github.com/caolan/async Saying that, I don't mind the way things look with the whole await/async stuff in C# and etc. However I d…

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 doab…

You do it like this (using async):

  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 */ }
  );
More lines than the foreach loop, but on the other hand, if this was an operation you wanted to do in parallel instead of sequentially, that'd be impossible with the simple loop construct.

Re: Callbacks as our Generation's Goto Statement

#173

I'm not buying the c# async/await kool-aid. Async, sure, I'm down with that, but I've used the c# async stuff now, and while it makes it the app somewhat faster, it has three major downsides (that I encountered): - Infects everything; suddenly your whole application has to be async. - Debugging becomes a massive headache, because you end up in weird situations where the request has completed before some async operati…

On the debugging issue, I agree that used to be terrible. See the awesome new Asynchronous Debugging feature in VS 2013: http://channel9.msdn.com/Shows/Visual-Studio-Toolbox/Asynchr...

Re: Callbacks as our Generation's Goto Statement

#174

I don't understand what the big deal is. Callbacks are OK. They're less cumbersome if the language you're using has smaller function definitions. Callbacks 'get crazy' when you've got more than one I think, and thankfully someone smart has made a library you can use to manage them! https://github.com/caolan/async Saying that, I don't mind the way things look with the whole await/async stuff in C# and etc. However I d…

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 doab…

Point taken, yet this particular problem with players asked one after the other is simpler than the case when players are each spawned their own Ask. Here's a simple solution to your problem:

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

Re: Callbacks as our Generation's Goto Statement

#175

Earlier quoted context omitted.

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.

C# 2 added generics (courtesy of the same people that did F#) and closures (albeit with syntax as verbose as JS). C# 3 added LINQ, which is a major breakthrough for end-users, although I'm not fond of the query language. So really, C# 3 just added in some basic features you expect from proper languages. I do understand this required a huge amount of work, esp. with the tooling required. C# 4 added dynamic (F# provide…

There are lots of work to do still on the CLR.

- Improve the GC algorithms, most JVMs have better GC algorithms

- Improve the code quality of the JIT and NGEN compilers, specially the set of applied optimizations

- Expose auto-vectorization and vector instructions (similar to Mono.SIMD)

- Expose something like C++ AMP on .NET.

Some of this was slightly improved on 4.5, but they could do more.

Re: Callbacks as our Generation's Goto Statement

#176

Earlier quoted context omitted.

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…

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

Because the existing type inference is good enough for the average enterprise programmer.

You know, those guys with good enough CS grades, that just do what they are told and don't even know HN exists.

Re: Callbacks as our Generation's Goto Statement

#177

Earlier quoted context omitted.

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

sometimes the truth hurts

What people like to accuse Java for, I have seen enterprise architects do such examples in C, Perl, C++, Java, C# and about any other language used in enterprise context.

Re: Callbacks as our Generation's Goto Statement

#178
post #141

(C/OS developer spiel) I'm sick of these app developers assuming that using "goto" is bad practice. The fact is that "goto" is used plenty in great production code you're probably running right now.[1] I'd like to know a cleaner way to abort a function into its cleanup phase when a function call returns an error. And "goto" statements are extremely simple to handle for even the most naive of compilers. [1] https://ww…

Exceptions

Re: Callbacks as our Generation's Goto Statement

#179
post #7

"I have just delegated the bookkeeping to the compiler." That's not obviously a good thing. Debugging the compiler (or just figuring out why it did something, even if correct) is far more difficult than debugging application code. Given the choice between implementing behavior with application code (or a library function) or adding semantics to the language, I prefer the former because it's much easier to reason abou…

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 th…

Thanks for mentioning the Bret Vector's talk. Quite interesting to watch.

Re: Callbacks as our Generation's Goto Statement

#180

shenanigans. Pyramids (at least in js) can be easily avoided by simply naming your functions. Treating them like the first class objects they are. Naming the function means you are no longer going to an arbitrary code block, but instead going to a concept whose name, doc string, and (through hoisting) position on the page illuminate its purpose. Callbacks aren't bad. Pyramids are bad. Stop writing pyramids. Nodejs al…

I'm fairly new to node.js, but having done some decent work in AS3/Flex (admittedly years ago) I'm a bit amassed that they didn't take a look how Adobe took on some of these "problems". I think it is a pity that the don't have callbacks for onError and onResult for instance. It would be easy to do and code would look nicer and with less noise. I suspect there are other niceties that could be learned from AS3/Flex and async/ event loop programming.
Post reply on HN