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