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

Re: Callbacks as our Generation's Goto Statement

#161

Post by eonil » Fri, Aug 16, 2013, 5:12 AM UTC

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 developers are not able to understand this concept.

Maybe true for the people around him.

I understand his position as a lead developer and an evangelist of Mono/C#, but this attitude is ridiculous.

Re: Callbacks as our Generation's Goto Statement

#162

Post by ufo » Fri, Aug 16, 2013, 5:16 AM UTC

NathanKP wrote: post #126

As someone who only recently switched to Node.js from PHP I personally haven't had any difficulty switching over to the callback frame of mind, and I haven't experienced the "callback hell" so many people complain about. At first I was hesitant to start with Node because I saw blog posts by people bemoaning the spaghetti callback code that they ended up with. But I haven't experienced any of that, although I am a rel…

I kinda have to disagree with you here. The problem of callback hell has nothing to do with the funcions being anonymous. In fact, you kinda want to have anonymous functions if you want to keep things as similar as possible to traditional code.

For example, when you have code like

    var x = f();
    print(x);

only a hardcore extremist like Uncle Bob would write it as

    var x;

    function start(){
       x = f();
       onAfterF();
    }

    function onAfterF(){
       print(x);
    }

because now your code logic is split among a bunch of functions, the variables had to be hoisted to where everyone can see them and the extra functions obscure control flow. In the first case its obvious that its a linear sequence of statements but in the second you cant be sure a-priori how many times onAfterF gets called, when it gets called and who calls it.

Coming back on topic, callback hell is not just about nesting and your current code still suffesr a bit from it. The real problem is that you cant use traditional structured control flow (for, while, try-catch, break, return, etc) and must instead use lots of explicit callbacks. Additionally, for this same reason, callback code looks very different from how you would normally write synchronous code and its a PITA if you ever have to convert a piece of code from one style to the other.

Re: Callbacks as our Generation's Goto Statement

#163

Post by manojlds » Fri, Aug 16, 2013, 5:19 AM UTC

cscheid wrote: post #137

nkuttler wrote: post #107

Earlier quoted context omitted.

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.

(for whatever's worth, I'm Brazilian)

Aren't you still American? ;)

As an Indian I am confused why only people of the US are called Amerians while two entire continents are called America.

And also, why we Indians are not considered Asians by the said Americans.

Re: Callbacks as our Generation's Goto Statement

#164

Post by ufo » Fri, Aug 16, 2013, 5:20 AM UTC

shadowmint wrote: post #114

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…

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

Re: Callbacks as our Generation's Goto Statement

#165

Post by ufo » Fri, Aug 16, 2013, 5:23 AM UTC

informatimago wrote: post #125

ScottBurson wrote: post #121

Earlier quoted context omitted.

Ah, but the real problem is not that these languages aren't Lisp, but that they aren't Scheme. People are being forced to write continuation-passing-style code by hand, which anyone would agree is painful. To allow user-level code to abstract away the need to write CPS, you need call/cc (or something like it).

You would never use call/cc directly. Like goto, it is a building block to be used in control abtraction macros.

Yes. The point is that while the idea of continuations exists, no one should be forced to write continuation-passing-style code by hand!

Re: Callbacks as our Generation's Goto Statement

#166

Post by marshray » Fri, Aug 16, 2013, 5:33 AM 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…

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.

Re: Callbacks as our Generation's Goto Statement

#167

Post by [deleted] » Fri, Aug 16, 2013, 5:52 AM UTC

danabramov wrote: post #54

ryan-allen wrote: post #37

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…

[deleted]

Re: Callbacks as our Generation's Goto Statement

#168

Post by anologwintermut » Fri, Aug 16, 2013, 5:55 AM UTC

MichaelGG wrote: post #72

danabramov wrote: post #45

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…

I'm not sure what you mean by break, but the comparable time line for Java, and C++ would show far less improvement in terms the addition of programing languages (as in the academic discipline) features (e.g lambdas, closures). They've done a far better job than most languages of actually advancing the language conceptually, not adding libraries/features.

Re: Callbacks as our Generation's Goto Statement

#169

Post by recursive » Fri, Aug 16, 2013, 5:56 AM UTC

MichaelGG wrote: post #160

brandonbloom wrote: post #73

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…

Probably because they don't know it's useless. I use and like C#. The type inference seems useful to me. Avoiding generic parameters on almost every linq extension method is a huge savings in comprehensibility. var x = new SuperDuperLongClassName(); is a nice savings in redundancy.

Where can I see an example of useful type inference?

Re: Callbacks as our Generation's Goto Statement

#170

Post by strictfp » Fri, Aug 16, 2013, 5:59 AM UTC

So... This article is basically saying that blocking style programming is a lot easier to read and write, and proceeds with demoing a lib which makes async calls look sync. So instead of doing this in $lang, why not invest time in making blocking style faster on the kernel level? Perhaps introduce actors or tasks in the kernel, so that every lang can benefit.