Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Faking Co-Routines, or Why Callback Hell Is Over (2014)

pandastrike.com

Post reply on HN
Print view View original

11–20 of 24 posts

Re: Faking Co-Routines, or Why Callback Hell Is Over (2014)

#11

Post by fao_ »

jestar_jokin wrote: post #9
erikpukinskis wrote: post #4

I have yet to see an "improvement" on callbacks, whether it's promises or fibers or generators, where the benefit in readability is worth the havoc it wreaks on my ability to debug the program. These days I write JavaScript using only functions, literals, variables, and the occasional prototype and it's amazing. I think many programmers have a desire to believe they are working on complex problems that demand sophist…

Unfortunately, Node.js decided that every callback should accept an error as the first argument to every callback. If you're chaining a bunch of callbacks, it's tedious and error-prone to add boilerplate to check for an error and handle it consistently in every callback , and violating the DRY principle. It's not easy to simply propagate the error to a higher-level handler.

If you're repeating yourself, then you could possibly abuse higher class functions to automatically generate error handling?

Re: Faking Co-Routines, or Why Callback Hell Is Over (2014)

#12

Post by apeace »

jestar_jokin wrote: post #9
erikpukinskis wrote: post #4

I have yet to see an "improvement" on callbacks, whether it's promises or fibers or generators, where the benefit in readability is worth the havoc it wreaks on my ability to debug the program. These days I write JavaScript using only functions, literals, variables, and the occasional prototype and it's amazing. I think many programmers have a desire to believe they are working on complex problems that demand sophist…

Unfortunately, Node.js decided that every callback should accept an error as the first argument to every callback. If you're chaining a bunch of callbacks, it's tedious and error-prone to add boilerplate to check for an error and handle it consistently in every callback , and violating the DRY principle. It's not easy to simply propagate the error to a higher-level handler.

I find the `async` library excels at this:

  var fs = require('fs');
  var async = require('async');
  async.waterfall([
    (cb) => fs.readFile('foo.txt', cb),
    (data, cb) => my_function(data, cb),
    (result, cb) => myDb.lookup(result, cb),
  ], (err, finalResult) {
    if (err) {
      console.error(err);
    } else {
      console.log(finalResult);
    }
  });
There are all sorts of helpful async primitives in there. I don't write Javascript without it!

Here is a link to the documentation: https://github.com/caolan/async

Re: Faking Co-Routines, or Why Callback Hell Is Over (2014)

#13

Post by jjn2009 »

jestar_jokin wrote: post #9
erikpukinskis wrote: post #4

I have yet to see an "improvement" on callbacks, whether it's promises or fibers or generators, where the benefit in readability is worth the havoc it wreaks on my ability to debug the program. These days I write JavaScript using only functions, literals, variables, and the occasional prototype and it's amazing. I think many programmers have a desire to believe they are working on complex problems that demand sophist…

Unfortunately, Node.js decided that every callback should accept an error as the first argument to every callback. If you're chaining a bunch of callbacks, it's tedious and error-prone to add boilerplate to check for an error and handle it consistently in every callback , and violating the DRY principle. It's not easy to simply propagate the error to a higher-level handler.

Its a problem yes, but the nature of javascript makes this a difficult problem to address. Node tried addressing this with the 'domain' module to help with propagating errors upward more generically:

https://nodejs.org/api/domain.html

But it was deprecated: https://github.com/nodejs/node/issues/66

promises are a very nice way of drying out error handling and cleaning up callbacks for now.

Re: Faking Co-Routines, or Why Callback Hell Is Over (2014)

#14

Post by jacobolus »

Azkar wrote: post #5

I don't understand why he talks about a javascript problem being solved, then goes on to show us examples in coffee script.

Paste the code into here if you’re having trouble following: http://coffeescript.org/#try:%7BliftAll%7D%20%3D%20require%2...

Re: Faking Co-Routines, or Why Callback Hell Is Over (2014)

#16

Post by scriby »

https://github.com/scriby/asyncblock-generators

That's a control flow solution I wrote on top of generators to make it a little easier to manage parallel tasks, timeouts, error handling, and so on.

I originally made asyncblock, which was based on fibers a few years ago. This module uses the same underpinnings as asyncblock, just based in generators instead of fibers.

Re: Faking Co-Routines, or Why Callback Hell Is Over (2014)

#18

Post by mchahn »

outside1234 wrote: post #15

Please: Do not use CoffeeScript in your examples. It is not common to have "readability" in CoffeeScript and it restricts a significant number of readers from being able to understand the code sample.

> restricts a significant number of readers from being able to understand

Can you seriously say you can't read it? It seemed easy to me.

Re: Faking Co-Routines, or Why Callback Hell Is Over (2014)

#19

Post by mateuszf »

erikpukinskis wrote: post #4

I have yet to see an "improvement" on callbacks, whether it's promises or fibers or generators, where the benefit in readability is worth the havoc it wreaks on my ability to debug the program. These days I write JavaScript using only functions, literals, variables, and the occasional prototype and it's amazing. I think many programmers have a desire to believe they are working on complex problems that demand sophist…

> I have yet to see an "improvement" on callbacks, whether it's promises or fibers or generators, where the benefit in readability is worth the havoc it wreaks on my ability to debug the program.

Chrome has support for debugging async code - for example you can step from one code block to the code in callback as if it would be executed sequentially. So the 'debuggability' is a problem which could be solved on the side of the tools. Of course the case where there would be one single standard for handling async would vastly simplify situation for the tools developers.

Post reply on HN