4 ms·
Oh come on. You've set up several straw man arguments here that don't apply to the real world situations that give rise to callback hell, like fetching multiple
by peterhunt 14y ago
Oh come on. You've set up several straw man arguments here that don't apply to the real world situations that give rise to callback hell, like fetching multiple rounds of data and aggregating many parallel callbacks at each step, or callbacks that are difficult to trace the origin of. Sure you can write good code with callbacks -- you can also write good code with goto and callcc -- but building a better abstraction makes code easier to write and maintain.
- Daniel_Newby 14y agoOr even worse, needing to cancel one pending callback but not another. No amount of syntax can save you from the difficulty of races and rollbacks.
- raganwald 14y agoSo, what we have here are: a. Post #1 gives strawman/overly simplistic argument for why callbacks are hell and FRP is great, and obscures example by comparing crappy syntax to elegant syntax. b. Post #2 gives straw man/overly simplistic argument for why callbacks are fine, and correctly points out the syntax issue. My takeaway is that both posts have some merit, but what we really need are some examples that go Apples to Apples on syntax AND show when callbacks are fine and when they aren't. Along with some realistic discussion of the complexity inherent in things like aggregating callbacks. Because, you know, we can only eliminate so much accidental complexity, and then we'll run into inherent complexity. And speaking as a fellow who appeals to authority by mentioning his experience writing a tool that did runtime analysis of multi-threaded applications... There is a lot of inherent complexity involved in writing truly asynchronous and parallel code when failure is expected.