3 ms·
This was easily foreseeable when he started on Node.js. The Twisted framework for Python had existed for years (decades?) before Node.js was created. Anyone f
by nas 9y ago
This was easily foreseeable when he started on Node.js. The Twisted framework for Python had existed for years (decades?) before Node.js was created. Anyone familiar with programming in that style knew of the issues with "callback hell".
I was the primary instigator of generators for Python. Part of my motivation was to do something like CSP (e.g. call-with-current-continuation, call/cc) without having to redo the whole language runtime and also kill off alternative Python implementations.
Generators in Python are limited to a single stack level. They have been extended to better support async IO coding. They work and are probably nicer than using callbacks but are still pretty ugly IMHO. The message passing that Erlang does is the best solution to this kind of concurrency. You can't really bolt that on a side of an existing language though.
Anyhow, I think Node is successful largely because Javascript is the language understood by web browsers. The non-blocking coding style is not some kind of magic bullet as Ryan originally suggested it was.
- k__ 9y agoSomehow I never experienced callback hell. It always felt like every other code-nesting problem to me. I mean, nobody talks about conditional hell, everyone acknowledges that you should flatten out your conditionals.
- sah2ed 9y agoCallback hell was real, especially if you worked on projects that decided to join the node.js bandwagon in its early days. Then promises happened. https://twitter.com/winterbe_/status/541868081308790784 https://twitter.com/winterbe_/status/541868081308790784
- mikewhy 9y agoWhy post a contrived meme as an example? Especially one with a sane solution[1] just below. [1]: https://pbs.twimg.com/media/B4W2AmaCAAA-heo.png https://pbs.twimg.com/media/B4W2AmaCAAA-heo.png
- sah2ed 9y agoIt's an exaggeration, yes, but it does correctly summarize how I felt when I had to work with node.js code bases before stuff like promises became mainstream.
- andreime 9y agoAn exaggeration could be written for any language. A decent programmer would not write code like the one you showcased as an example for callback hell. This https://docs.spring.io/spring/docs/2.5.x/javadoc-api/org/springframework/aop/framework/AbstractSingletonProxyFactoryBean.html https://docs.spring.io/spring/docs/2.5.x/javadoc-api/org/spr... is not an exaggeration and I still would not use it to showcase how I felt when I had to work with Java developers.
- Scarbutt 9y agoIn case you are just referring to the browser, callback hell is way more invasive in nodejs than in the browser.
- bartread 9y agoI'm inclined to agree. To me callback hell is a symptom of lazy, or perhaps just ignorant, programming. It was never a necessity: if things are getting out of control, create a named function and pass in the name as the callback to make things more readable.
- z3t4 9y agoWhen starting with Node.JS I did experience callback hell for about half a year before I found a good tutorial on how to manage the callbacks, and it finally clicked, since then, managing callbacks has become a second nature. The magic trick is to use named child functions instead of anonymous and self calling functions, so you can take advantage of the closure. I find programming this way even easier then writing in a serial non async language, because of the heavy use of function state instead of global state, and I love that in Node.JS modules are not just a "include file" and actually a object that works just like any other object, and can be used in function scope and closures. So instead of importing a bunch of variables to the top scope, you can require them locally and just by looking at the function you can see where all the variables come from, you don't have to know about the outside world to understand what the function does!