I often write synchronous methods that include control flow that nests three deep (say try/finally, if/then/else, and a for loop). Often it's easier to read this code than it would be if everything were split out into separate named methods.
Why would the same not be true of asynchronous methods, assuming that the technology was there to enable it (as it is in C#)?
I agree. Sometimes inline asynchronous callbacks work, just like inline code blocks for if statements or for loops. You just need to train your eye to read them as if they were inline code blocks for an if/then/else block or a for loop.
But sometimes when you get many levels deep in if statements or if a synchronous function starts to reach the hundreds of lines it makes sense to break it up into multiple functions that each have a sensible semantic meaning and which fit on a screen or so. This makes the synchronous code easier to read.
The same goes for asynchronous callback functions. The callback hell that I see most often happens when people have hundreds of lines of inception style anonymous callback functions inside of anonymous callback functions. In this case, just as with the synchronous function that got excessively heavy it makes sense to break things up into multiple functions.
It's all about finding the right balance, and when you do the results are very readable and easy to understand whether you are writing synchronous or asynchronous code.
Why should that be the case? Creating all the extra methods is going to create lots of new points of indirection, the new methods are likely to be tightly coupled anyway and breaking the nesting might mean you have to hoist a bunch of variables into an outer scope.
this use case is inherently more complicated than any of the control flow structures you mention here. You are introducing a new closure, and you don't know when the function is going to be executed.
Why would the same not be true of asynchronous methods, assuming that the technology was there to enable it (as it is in C#)?