3 ms·

Not saying you are wrong (I don't know enough to disagree) but if asynchronous program is solved in node/javascript, why is there the need for all these post on

by SeanDav 12y ago

Not saying you are wrong (I don't know enough to disagree) but if asynchronous program is solved in node/javascript, why is there the need for all these post on callbacks, streams, promises, fibres etc? Can you expand more on your comment and/or point to some references?

doublerebel 12y ago
"Callback hell" is very effective linkbait for a title, there is not a need for the post. Promises are an effective implementation of control flow for ES5 JS, but don't really improve program structure. They are most useful "under-the-hood", as TameJS/Iced-CS creates when compiling. The overarching solution is to be "flat" by using small, composable functions. Lazy.js and Highland.js force the user to do this but require learning a specific syntax. Streams make this technique easier to reason about (easier say, than Transducers or Generators), but the goal is the same: operate on one object at a time with one purpose, and return a result in a standard manner so it's easy to consume with the next function. This is good practice, but leaning on one of these libraries is an excuse to force the practice. Chained callbacks is JS looking from the inside out; looking from the outside in, we see this practice is solved by many other languages [1] -- not just serial calls but parallel also! C#, Scala, Python, Java, Dart, Spiderjs and more have implementations of Futures [2]. Fibers implement Futures but require a native module for V8 -- since they are not portable outside Node they don't have great adoption and aren't used in almost any node.js modules: only ~100 out of the endless ecosystem [3]. Fibers, Async.js, and Highland also aren't syntactically an improvement over Promises -- the point of programming, which devs will get tunnel vision and forget -- is to leverage the language to do more work for less keystrokes/manhours [4]. The compiler should create control flow for my code, not the other way around. There should be no reason to learn a complex API just to get serial/parallel calls, when a simple keyword addition to the language will suffice. Not to mention, await/defer is so readable that new devs can start working with async code right away, without needing to research. This is not the case with promises/fibers/asyncjs/highland or whatever flavor-of-the-month a shop has picked for control flow. [1] https://github.com/KjellSchubert/promise-future-task https://github.com/KjellSchubert/promise-future-task [2] http://en.wikipedia.org/wiki/Futures_and_promises#List_of_implementations http://en.wikipedia.org/wiki/Futures_and_promises#List_of_im... [3] https://www.npmjs.com/package/fibers https://www.npmjs.com/package/fibers [4] http://blog.teamleadnet.com/2013/08/async-await-in-net-is-not-for.html http://blog.teamleadnet.com/2013/08/async-await-in-net-is-no...

by SeanDav 12y ago

doublerebel 12y ago

"Callback hell" is very effective linkbait for a title, there is not a need for the post. Promises are an effective implementation of control flow for ES5 JS, but don't really improve program structure. They are most useful "under-the-hood", as TameJS/Iced-CS creates when compiling. The overarching solution is to be "flat" by using small, composable functions. Lazy.js and Highland.js force the user to do this but require learning a specific syntax. Streams make this technique easier to reason about (easier say, than Transducers or Generators), but the goal is the same: operate on one object at a time with one purpose, and return a result in a standard manner so it's easy to consume with the next function. This is good practice, but leaning on one of these libraries is an excuse to force the practice. Chained callbacks is JS looking from the inside out; looking from the outside in, we see this practice is solved by many other languages [1] -- not just serial calls but parallel also! C#, Scala, Python, Java, Dart, Spiderjs and more have implementations of Futures [2]. Fibers implement Futures but require a native module for V8 -- since they are not portable outside Node they don't have great adoption and aren't used in almost any node.js modules: only ~100 out of the endless ecosystem [3]. Fibers, Async.js, and Highland also aren't syntactically an improvement over Promises -- the point of programming, which devs will get tunnel vision and forget -- is to leverage the language to do more work for less keystrokes/manhours [4]. The compiler should create control flow for my code, not the other way around. There should be no reason to learn a complex API just to get serial/parallel calls, when a simple keyword addition to the language will suffice. Not to mention, await/defer is so readable that new devs can start working with async code right away, without needing to research. This is not the case with promises/fibers/asyncjs/highland or whatever flavor-of-the-month a shop has picked for control flow. [1] https://github.com/KjellSchubert/promise-future-task https://github.com/KjellSchubert/promise-future-task [2] http://en.wikipedia.org/wiki/Futures_and_promises#List_of_implementations http://en.wikipedia.org/wiki/Futures_and_promises#List_of_im... [3] https://www.npmjs.com/package/fibers https://www.npmjs.com/package/fibers [4] http://blog.teamleadnet.com/2013/08/async-await-in-net-is-not-for.html http://blog.teamleadnet.com/2013/08/async-await-in-net-is-no...