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

261–270 of 287 posts

Re: Callbacks as our Generation's Goto Statement

#261

Post by ygra »

anonymoushn wrote: post #33
rgbrgb wrote: post #6

Earlier quoted context omitted.

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.

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

In fact, Eric Lippert, when first introducing that feature on his blog started with a five-part series about continuations and only in the end got around to explaining what that was all about. It was a very nice read.

Re: Callbacks as our Generation's Goto Statement

#262

Post by gambler »

NathanKP wrote: post #259
gambler wrote: post #255

Earlier quoted context omitted.

I'm tired to the utmost degree of all these posts about people (supposedly) coming from PHP/C#/Ruby/Python background and seeing "absolutely no problems" with JS syntax, object model and programming paradigms. There are problems. They are objectively there. If you don't see them, you have to check your critical thinking skills, rather than imply that everyone outside of elite JS circles are simply too ignorant to und…

Well in addition to not having a problem with callback hell I also haven't used a debugger in more than three years, so I guess I'm just weird. As I said I like to write unit tests with my named callbacks. This allows me to test the callbacks as well as the root level functions that make use of these callbacks to ensure that everything is working perfectly. When I follow this model it is extremely rare that I ever en…

When someone gives you a sufficiently large codebase written by other people and asks why when they click A they get B, you have two options: 1. Read the code and try to reason about it. 2. Fire up the debugger and replicate user actions.

Guess what? Callbacks in JS make option #1 significantly harder, since they are, essentially, runtime weakly typed mechanism for code composition.

Re: Callbacks as our Generation's Goto Statement

#263

Post by OldSchool »

As soon as you have anything involved that's async to your process or thread, you're going to operate most efficiently with something along the lines of a callback. I don't see them as a Goto at all; they're much more like interrupt handlers or at least event handlers if you want jump ahead a generation from there.

Re: Callbacks as our Generation's Goto Statement

#264

Post by ufo »

stagas wrote: post #249
ufo wrote: post #248

Earlier quoted context omitted.

Of course its complicated for no reason. Its an example! The same logic would apply if I had 5+ nontrivial lines of code instead of just a print statement.

I'm sorry, hardly ever had an issue with callback-based programming. If you're used to imperative, maybe the problem is that you're making a mess because you're adapting from a different style and complicating it with workarounds, you need to be functional.

I dont think its a matter of functional vs imperative. In fact, functional languages give some of the best tools to avoid having to write callbacks by hand. For example, in LISPs the language tends to have explicit support for converting non callback code to CPS (call/cc and thigns like that) and in Haskell you have do-notation to get rid of the nesting and hide the callbacks behind some syntax sugar.

Re: Callbacks as our Generation's Goto Statement

#265

Post by lists »

Completely OT, but when Dijkstra says:

>My second remark is that our intellectual powers are rather geared to master static relations and that our powers to visualize processes evolving in time are relatively poorly developed. For that reason we should do (as wise programmers aware of our limitations) our utmost to shorten the conceptual gap between the static program and the dynamic process, to make the correspondence between the program (spread out in text space) and the process (spread out in time) as trivial as possible.

He's touching on a crucial point in Immanuel Kant's philosophy. Kant theorized that though humans received their sensations as a constant stream of input in time (which is an internal condition of human beings, not a feature of bare reality), we can't actually do anything with that stream without applying concepts so as to form concrete (or abstract) objects, i.e. chairs, black holes, mothers, etc. But how would our minds know when to apply this concept or the other? Kant's reply was that our minds look for little clues called 'schematisms' which tell us what the most appropriate fundamental concept to apply to a part of the stream is, upon which others could be combined to produce objective representations we can think and act upon.

Almost a hundred years later, Nietzsche will claim (paraphrasing) that a measure of strength in a human being is the extent to which to which they can 'consume' phenomena in time, weakness being how direly one needs to apply a static idea to phenomena (like morals, stereotypes, prejudices, cause and effect, etc).

I'm just noting an interesting entry point into an old philosophical conversation. If it's understandable then I hope someone finds it interesting.

Re: Callbacks as our Generation's Goto Statement

#266

Post by sirmarksalot »

thedamhattter wrote: post #250
sirmarksalot wrote: post #195

Earlier quoted context omitted.

Another example: a lot of old code bases use "goto" for error handling. I'm assuming the Linux kernel still does this. Now we've formalized that behavior into exceptions.

Formalized that behavior into exceptions? Last I checked using exceptions for control flow was a BAD practice. In c at least, breaking out of an error condition is still best handled with a goto (where you can clean up all matter of memory in an organized fashion without littering your code with if elses).

This discussion sort of hinges on being able to explain why something is a bad practice or not. What problems in particular do exceptions cause, and in which situations do they not apply? In other words, is it ever right to throw an exception, or is every line of code in your program "control flow?"

It's been nearly a decade since I've used plain C, so I'm not 100% sure, but I was under the impression that it doesn't have any native support for exceptions. So yes, under those circumstances "goto" would definitely be appropriate.

In C#, you can implement resource ownership with the IDisposable interface and "using" keyword, which guarantees that once you leave the block (via an exception or regular control flow), the resource is cleaned up. In C++, you can use the RAII pattern that another commenter brought up. What other problems do exceptions introduce?

In my as-functional-as-is-practical programming philosophy, you throw an exception when there is no valid output for your function. Whether or not that's recoverable is up to the client to decide. Nulls are an extremely poor substitute for this, as they push the responsibility of output validation onto the client, and every single line of code must be enclosed in an "if (foo != null)" block.

EDIT: Removed unproductive "zinger" at end.

Re: Callbacks as our Generation's Goto Statement

#267

Post by angersock »

raverbashing wrote: post #212
danabramov wrote: post #202

Earlier quoted context omitted.

This is simply not true. You can use any C# library without using async (code rewriter). You'd still be using Tasks but there is nothing special about them (no compiler magic). They're just futures on which you can schedule continuations.

I'm not talking about C#, but about libraries in other languages that support async behaviour

PDFJS--the PDF reading package from Mozilla--is a gross offender in this regard; the mix of sync and async, and the somewhat arbitrary nature of which is which, is pretty annoying.

Re: Callbacks as our Generation's Goto Statement

#268

Post by marshray »

danabramov wrote: post #200
marshray wrote: post #166

Earlier quoted context omitted.

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

I'm sure Busy isn't meant to represent state—it's a property whose setter and getter call a spinning wheel UI element's StartAnimating and StopAnimating. It's a very common practice in iOS view controllers. That's what I read anyway.

That sounds like state to me.

Re: Callbacks as our Generation's Goto Statement

#269

Post by danabramov »

marshray wrote: post #268
danabramov wrote: post #200

Earlier quoted context omitted.

I'm sure Busy isn't meant to represent state—it's a property whose setter and getter call a spinning wheel UI element's StartAnimating and StopAnimating. It's a very common practice in iOS view controllers. That's what I read anyway.

That sounds like state to me.

Do you have any other method of updating the UI without calling corresponding methods? I'm lost on your argument.
Post reply on HN