Callbacks as our Generation's Goto Statement

Re:Callbacks as our Generation's Goto Statement by rgbrgb on Thursday August 15, 2013 @06:13PM (#6220931)

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.

[ Parent | on HN ]

Re:Callbacks as our Generation's Goto Statement by stcredzero on Thursday August 15, 2013 @06:38PM (#6221038)

> the visual structure of callback-oriented programs doesn't reflect the order of execution.

One of my bosses made this assertion about Object Oriented code that followed the Law of Demeter and other OO best practices. I don't think he's entirely the best OO person, or entirely on the right track. However, I would venture to say that all programming paradigms hit a point where visualizing the flow of control gets exhausting. If it's not a twisty maze of little methods, all looking the same, then it's a twisty maze of callbacks...

[ Parent | on HN ]

Re:Callbacks as our Generation's Goto Statement by jfarmer on Thursday August 15, 2013 @07:13PM (#6221192)

Callback-oriented code is different. With by-the-book OOP code you're still executing one line at a time. You might be teleporting in space, which has its own problems, but your code still reflects the order of execution.

With callback-oriented code you're teleporting in space and time.

They can both make it hard to trace the path of execution. At least with OOP code you have a sensible stack trace, though. ;)

[ Parent | on HN ]

Re:Callbacks as our Generation's Goto Statement by stcredzero on Friday August 16, 2013 @01:51PM (#6225594)

True about the stack trace, but teleporting around in space is still the same kind of difficulty. You're taking a whole and scattering it around.

[ Parent | on HN ]

Re:Callbacks as our Generation's Goto Statement by ufo on Saturday August 17, 2013 @12:48PM (#6229563)

I think he was referring to features like call/cc. They are very similar to C#'s await in that you write regular looking code and the language does the heavy lifting of figuring out what the real continuation is supposed to be.

[ Parent | on HN ]

Re:Callbacks as our Generation's Goto Statement by anonymoushn on Thursday August 15, 2013 @06:49PM (#6221099)

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

[ Parent | on HN ]

Re:Callbacks as our Generation's Goto Statement by dragonwriter on Thursday August 15, 2013 @06:59PM (#6221132)

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 efficient to implement specialized weaker (but good enough for most key use cases) forms of the most important applications of continuations.

[ Parent | on HN ]

Re:Callbacks as our Generation's Goto Statement by anonymoushn on Thursday August 15, 2013 @07:10PM (#6221176)

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.

[ Parent | on HN ]

Re:Callbacks as our Generation's Goto Statement by ygra on Friday August 16, 2013 @05:47PM (#6226908)

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.

[ Parent | on HN ]