Comment by nas | Hacker News Reader

Comment by nas | Hacker News Reader

Parent Full thread

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.

Somehow 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.

I'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.

When 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!

In case you are just referring to the browser, callback hell is way more invasive in nodejs than in the browser.

Callback 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

Why 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

It'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.

An 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/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.

Reply on news.ycombinator.com