4 ms·

Isn't callback hell referencing to the fact that you can't easily access the previous result of computation without nesting closures inside one another? It see

Isn't callback hell referencing to the fact that you can't easily access the previous result of computation without nesting closures inside one another? It seems to me that first time I really avoided cb hell is when I started using async/await.

z3t4 9y ago
var timeCreated = new Date(); button.onclick = function buttonClicked(clickEvent) { var timeClicked = new Date(); console.log("Button was created " + (timeClicked-timeCreated) + "ms ago"); } Lets say you have two functions: Jon from support, and Jane from billing. Both of them have access to the customer database. Now a customer calls, the customer hits 1 for support and Jon gets the call, while Jon is on the phone, another customer calls, hits 2 for billing and Jane gets the call. You can have a very complex setup using just functions, and some variables to keep track of things, maybe an array for implementing a call queue. You can choose when to run in serial, and when to run in parallel, and make a limit on how many calls that can run at any given time. And every possible error handled and managed. Promises, async/await and futures are only leaky abstractions that will just complicate things. They look nice for simple examples without any error handling, but when you want to do real world stuff you have to think about how they work behind the scenes.
- Mitranim 9y ago
  It sounds like you're saying "explicit FSMs are strictly more powerful than promises/coroutines". Which is true. However, they're inherently difficult to program. In my view, the key to simplicity and correctness of programs is reducing the amount of states the program can possibly have. Isolating a piece of code into a blocking sequence seems like a fairly good way of doing it. Not sure what you mean by "simple examples without error handling". Just like normal synchronous code, promises and coroutines use exceptions, which have the nice property of composability: one catch for several statements/promises. So error handling is the same as in synchronous code. Now granted, there's a LOT of async/reactive problems where sequential abstractions like promises are irrelevant. GUI programming comes to mind, where you want the view to reflect some reactive state that changes in arbitrary order.

z3t4 9y ago

var timeCreated = new Date(); button.onclick = function buttonClicked(clickEvent) { var timeClicked = new Date(); console.log("Button was created " + (timeClicked-timeCreated) + "ms ago"); } Lets say you have two functions: Jon from support, and Jane from billing. Both of them have access to the customer database. Now a customer calls, the customer hits 1 for support and Jon gets the call, while Jon is on the phone, another customer calls, hits 2 for billing and Jane gets the call. You can have a very complex setup using just functions, and some variables to keep track of things, maybe an array for implementing a call queue. You can choose when to run in serial, and when to run in parallel, and make a limit on how many calls that can run at any given time. And every possible error handled and managed. Promises, async/await and futures are only leaky abstractions that will just complicate things. They look nice for simple examples without any error handling, but when you want to do real world stuff you have to think about how they work behind the scenes.

Mitranim 9y ago
It sounds like you're saying "explicit FSMs are strictly more powerful than promises/coroutines". Which is true. However, they're inherently difficult to program. In my view, the key to simplicity and correctness of programs is reducing the amount of states the program can possibly have. Isolating a piece of code into a blocking sequence seems like a fairly good way of doing it. Not sure what you mean by "simple examples without error handling". Just like normal synchronous code, promises and coroutines use exceptions, which have the nice property of composability: one catch for several statements/promises. So error handling is the same as in synchronous code. Now granted, there's a LOT of async/reactive problems where sequential abstractions like promises are irrelevant. GUI programming comes to mind, where you want the view to reflect some reactive state that changes in arbitrary order.