> Callback-heavy programming is what you get when your language doesn't support better ways of controlling context.
UI programming is callback heavy, but I doubt that any language will support "better" ways for that.
So basically UI programmers are used to callbacks, others not that much, and now that event-loop servers are becoming popular, we see confusion from people not familiar with events.
Server-side people just need to figure out how to use callbacks properly and everything is gonna be fine.
All people need to understand is to nest callbacks properly, nested callbacks are the things that confuse most people.
> For Python, you can get the benefits of asynchronous IO without callback hell if you use the Stackless fork.
You can't just abstract away every programing feature that seems hard and expect everything to be fine, it just doesn't work that way, Java developers are still suffering because Java tries real hard to abstract memory management.
So basically UI programmers are used to callbacks, others not that much, and now that event-loop servers are becoming popular, we see confusion from people not familiar with events.
I don't think that's right. There is a huge difference. UI callbacks ("onClick" and the like) execute synchronously. But the callbacks in event servers execute at completely different times. Indeed, they're typically nested inside code that has long since terminated. This is what causes the learning curve, not grokking events or functions-as-values, which any half-decent programmer can easily do in the unlikely event that they didn't a long time ago. Indeed, the way we write asynchronous callbacks is cognitively dissonant with everything we've been trained to understand about scoping. The idea of a nested scope that doesn't mean "contained within" or "covered by", but rather "at some unknown time later", is inconsistent enough with how programming languages normally work that it can easily trip you up even after you get good at it.
Asynchronous programming is a very different thing than e.g. browser UIs in Javascript. I've programmed those for years. It still took me a long time to get my head around async servers.
I don't think the comparison with UI is so apt. Sure, they both use callbacks, but the granularity is quite different. In UI callbacks, you don't need to insert your own "scheduling points" as you need in explicity asynchronous programming. Mostly, you write functions that reacts to the events generated by the UI, but within those event handler, your own code is mostly synchronous.
I wonder why you mean by using callbacks properly ? The critical point mentioned by Guido is error/corner-case handling: the idiomatic callback-based code I have seen becomes difficult very quickly. I have not seen a case where e.g. deferred-based code ala twisted has been simpler than gevent.
Rob Pike designed one of the spiritual ancestors of Go, Squeak ( http://doc.cat-v.org/bell_labs/squeak/ ) using the CSP model of concurrency specially to build (G)UIs.
UI programming is callback heavy, but I doubt that any language will support "better" ways for that.
So basically UI programmers are used to callbacks, others not that much, and now that event-loop servers are becoming popular, we see confusion from people not familiar with events.
Server-side people just need to figure out how to use callbacks properly and everything is gonna be fine.
All people need to understand is to nest callbacks properly, nested callbacks are the things that confuse most people.
> For Python, you can get the benefits of asynchronous IO without callback hell if you use the Stackless fork.
You can't just abstract away every programing feature that seems hard and expect everything to be fine, it just doesn't work that way, Java developers are still suffering because Java tries real hard to abstract memory management.