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

21–24 of 24 posts

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

#21

Post by doublerebel »

fao_ wrote: post #11
jestar_jokin wrote: post #9

Earlier quoted context omitted.

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?

Yes, there are libs like errTo [1] and iced-error/make_esc [2]. Not to mention Promise.promisify(). Long solved problem.

[1]: https://www.npmjs.com/package/errto

[2]: https://www.npmjs.com/package/iced-error

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

#22

Post by Azkar »

ludamad wrote: post #10
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.

There really shouldn't be an difficulty seeing how it maps to JavaScript. CoffeeScript is pretty clean for code examples.

It's not that it's difficult to understand, it's about comparing apples to apples.

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

#23

Post by erikpukinskis »

cyphar wrote: post #6
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…

> It helps to remember > function a() { b(function() { //etc }) } is equivalent to > function a() { b(c) } function c() { //etc } which is not particularly more verbose. And as a side benefit, refactoring that way gives you an opportunity to make c() self-documenting. It's not always equivalent, since you can have closures.

That's true, and I use closures sometimes. But they are a performance and readability anti-pattern, and it's often better to either pass in or bind the data you actually need.

In some sense closures are globals and globals are bad.

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

#24

Post by erikpukinskis »

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 would have to look at your code, but generally if you have a long callback chain and you're trying to propagate errors up it you are doing something wrong. Are you really working on 10 nested activities simultaneously, or are you just nesting things because it's convenient and you don't want to think about how to do things in stages?

If you're trying to convince me that "callbacks become painful in situation X" you really don't need to. I know that. What I'm saying is that 9 times out of 10, the answer to the question "do we really want to be in situation X in the first place?" is "no". But instead of getting out of a bad situation by refactoring, people just write crazier and crazier control structures (i.e. promises) to make those bad situations workable.

Post reply on HN