3 ms·

Why do people insist on analysing things using analogies? Analogies are useful for explaining a concept that might not be obvious. Saying callbacks are like g

Why do people insist on analysing things using analogies? Analogies are useful for explaining a concept that might not be obvious. Saying callbacks are like gotos, gotos are bad, therefore callbacks are bad is ridiculous. And he gives some sample code where the 'problem' is nothing to do with callbacks, its just nested lambdas. In fact I find that code quite easy to read, and would be very interested in seeing the same functionality implemented some other way, bearing in mind it is quite a difficult problem to synchronize multiple async operations and usually requires horrible code using multiple mutex.

zowch 13y ago
I'm confused as to why you think the code presented in the blog post isn't an example of 'the same functionality implemented some other way'. The await code is almost undeniably more straightforward and the exceptional cases more obvious to handle. He also doesn't seem to be making a weird logical leap the way you claim he is. He's not really using an analogy. He's saying callbacks are bad the same way goto is bad, in that they make the logical structure of a program's execution non-obvious, particularly over time and when being modified.
- adamconroy 13y ago
  I'm not saying the await syntax isn't useful or a better way to implement that problem. The title and opening of the article is comparing callbacks with gotos. It would be logical if he titled the article "C# Await syntax trumps callbacks when multiple callbacks need to be synchronised". Any syntax can be used to create spaghetti code. Callbacks only become spaghetti like when nested / chained / abused. I've written hundreds of API methods using callbacks that I believe are very clean. I've recently written a large API which makes async service calls that follows this pattern : void GetInvoiceHistory(int? customerId, Action<List<InvoiceItem>> callback, Action<string, Exception> exceptionCallback); The consumer of this API does not need await, there is no need to nest callbacks, there is no need for try/catch and it is very clean to work with. So IMHO, stating that callbacks are this generation's gotos is a pile of shit.

zowch 13y ago

I'm confused as to why you think the code presented in the blog post isn't an example of 'the same functionality implemented some other way'. The await code is almost undeniably more straightforward and the exceptional cases more obvious to handle. He also doesn't seem to be making a weird logical leap the way you claim he is. He's not really using an analogy. He's saying callbacks are bad the same way goto is bad, in that they make the logical structure of a program's execution non-obvious, particularly over time and when being modified.

adamconroy 13y ago
I'm not saying the await syntax isn't useful or a better way to implement that problem. The title and opening of the article is comparing callbacks with gotos. It would be logical if he titled the article "C# Await syntax trumps callbacks when multiple callbacks need to be synchronised". Any syntax can be used to create spaghetti code. Callbacks only become spaghetti like when nested / chained / abused. I've written hundreds of API methods using callbacks that I believe are very clean. I've recently written a large API which makes async service calls that follows this pattern : void GetInvoiceHistory(int? customerId, Action<List<InvoiceItem>> callback, Action<string, Exception> exceptionCallback); The consumer of this API does not need await, there is no need to nest callbacks, there is no need for try/catch and it is very clean to work with. So IMHO, stating that callbacks are this generation's gotos is a pile of shit.