News for hackers. Stuff that matters.

A comment on The Problem of Async Programming, and a Crazy Idea for Solving It.

Re:The Problem of Async Programming, and a Crazy Idea for So... by ricardobeat on Monday December 10, 2018 @07:20PM (#18652332)
Callback hell was never about promises, but callbacks (!) which would require a third-party library or some gymnastics to implement control flow. Promises and async/await both solve it reasonably well. The problem presented can be rewritten as:

    Promise.all([
        doA().then(a => doC(a).then(c => [a, c])),
        doB().then(b => doD(b), b_; return b; })
    ]).then(([a, c], b) => doE(c, a, b))
No need for `new Promise(resolve => ...)`. Or with async/await:

    const [a, b] = Promise.all([doA(), doB()])
    doD(b)
    const c = await doC(a)
    doE(c, a, b)
Is it worth introducing the complexity of visual programming to solve this 'problem'? I have a much harder time understanding the graph than the code.
[ Parent | on HN ]
Re:The Problem of Async Programming, and a Crazy Idea for So... by lorean_victor on Monday December 10, 2018 @07:21PM (#18652341)
yeah I think the article actually starts with that Promise-based code snippet. Even the sequential graph is based on the promise-based code.
[ Parent | on HN ]
Re:The Problem of Async Programming, and a Crazy Idea for So... by ricardobeat on Monday December 10, 2018 @07:28PM (#18652370)
Look closer - the original is way more convoluted - there is no reason to use `new Promise` constructors when you're dealing with other promise-returning functions.
[ Parent | on HN ]
Re:The Problem of Async Programming, and a Crazy Idea for So... by lorean_victor on Monday December 10, 2018 @07:41PM (#18652434)
yes you are right the constructors aren't indeed needed.

as for the complexity of the graph, basically the way I see it is that even this promised based method is a way to solve the problem of putting the graph into the proper promise-based format (for example, chain doA and doC and return an array of their result) vs simply drawing the intended graph. I mean it does take sometime to get used to it specially if you are really used to just working with code (which I myself originally was), but since the graph is the more intuitive way to represent it compared to other methods, after going through the learning curve it seems to be less complex and easier to manage.

that said its not like I have conducted proper academic research on the matter and it might as well be a pretty subjective thing.

[ Parent | on HN ]