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

The Problem of Async Programming, and a Crazy Idea for Solving It

medium.com

Post reply on HN
Print view View original

11–20 of 25 posts

Re: The Problem of Async Programming, and a Crazy Idea for Solving It

#11

Post by lorean_victor »

jmull wrote: post #5

> To see that for yourself, try to re-write our async code snippet again using only async/await statements and see how does that pan out. With async/await, wouldn't the example just be: let aOut = doA(); let bOut = doB(); let cOut = doC(aOut); doD(bOut); doE(cOut, aOut, bOut); That is, it looks the same as the sync version. The difference is in the "do" functions themselves: they would be async (meaning they return a…

so in your code sample, would 'aOut' be a promise or a value? in case it is a promise, then basically doC() would needed to be re-written to handle when it gets a promised value instead of an actual value, and if not, then doA() must be invoked synchronously, i.e. the `let bOut = doB()` statement must be awaiting `let aOut = doA()` statement which is not what the desired async execution flow is.

Re: The Problem of Async Programming, and a Crazy Idea for Solving It

#12

Post by ricardobeat »

lorean_victor wrote: post #10
ricardobeat wrote: post #8

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 => ...)…

yeah I think the article actually starts with that Promise-based code snippet. Even the sequential graph is based on the promise-based code.

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.

Re: The Problem of Async Programming, and a Crazy Idea for Solving It

#13

Post by lorean_victor »

flukus wrote: post #4

I don't think the leap to visual programming is necessary considering we have tools like make that work essentially identically and remain text based. All this is really doing is moving the dependency declaration to lines instead of words and this would get very messy very quickly. An example in make (if I'm reading in the right direction) format which I'd argue is more readable and could scale much better would be:…

Shouldn't it be like

doE: doC, doB, doA doD: doB

etc?

anyways the problem with this approach is that doD() is assumed to be a general function (or statement or async command) that is not by definition bound to doB(), but rather in this specific case we need it to be executed after doB() is done.

Re: The Problem of Async Programming, and a Crazy Idea for Solving It

#14

Post by lorean_victor »

ricardobeat wrote: post #12
lorean_victor wrote: post #10

Earlier quoted context omitted.

yeah I think the article actually starts with that Promise-based code snippet. Even the sequential graph is based on the promise-based code.

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.

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.

Re: The Problem of Async Programming, and a Crazy Idea for Solving It

#15

Post by jmull »

lorean_victor wrote: post #11
jmull wrote: post #5

> To see that for yourself, try to re-write our async code snippet again using only async/await statements and see how does that pan out. With async/await, wouldn't the example just be: let aOut = doA(); let bOut = doB(); let cOut = doC(aOut); doD(bOut); doE(cOut, aOut, bOut); That is, it looks the same as the sync version. The difference is in the "do" functions themselves: they would be async (meaning they return a…

so in your code sample, would 'aOut' be a promise or a value? in case it is a promise, then basically doC() would needed to be re-written to handle when it gets a promised value instead of an actual value, and if not, then doA() must be invoked synchronously, i.e. the `let bOut = doB()` statement must be awaiting `let aOut = doA()` statement which is not what the desired async execution flow is.

Yes, aOut would be a promise. It would look like this:

    async function doA() {
        ...
        return "the-result-of-a";
    }
(Which returns a promise. Assuming execution reaches that last line of my sample code, the promise will resolve to "the-result-of-a" when you "await" it.)

> ...then basically doC() would needed to be re-written to handle when it gets a promised value instead of an actual value

Well, wait a minute... it wasn't written in the first place! Let's write it though. It would look like this:

   async function doC( param ) {
       ...
       // we use "await param" where we want to
       // access the value of param. e.g.:
       const paramValue = await param;

       ...
    }
So not bad.

Re: The Problem of Async Programming, and a Crazy Idea for Solving It

#16

Post by lorean_victor »

jmull wrote: post #15
lorean_victor wrote: post #11

Earlier quoted context omitted.

so in your code sample, would 'aOut' be a promise or a value? in case it is a promise, then basically doC() would needed to be re-written to handle when it gets a promised value instead of an actual value, and if not, then doA() must be invoked synchronously, i.e. the `let bOut = doB()` statement must be awaiting `let aOut = doA()` statement which is not what the desired async execution flow is.

Yes, aOut would be a promise. It would look like this: async function doA() { ... return "the-result-of-a"; } (Which returns a promise. Assuming execution reaches that last line of my sample code, the promise will resolve to "the-result-of-a" when you "await" it.) > ...then basically doC() would needed to be re-written to handle when it gets a promised value instead of an actual value Well, wait a minute... it wasn't…

yeah really not bad at all, didn't think of that solution originally. edited the article accordingly.

Re: The Problem of Async Programming, and a Crazy Idea for Solving It

#17

Post by karmakaze »

lorean_victor wrote: post #9
karmakaze wrote: post #7

Doesn't seem new at all, just like functional programming with lazy values. The new part isn't the async it's the visual programming of which there are others. Does incorporation async make visual programming different?

Yeah I don't think so that on its own the visual programming makes any difference (or even adds any value). The main point here is that the "visual programming" is coincidentally a solution for async programming.

The actual problem with async functions is mixing them with non-async ones. Having all futures/promises makes it easy. Now if the visual style could represent current mixed js code, that could be awesome for display and editing I'd have to try before deciding.

Re: The Problem of Async Programming, and a Crazy Idea for Solving It

#19

Post by lorean_victor »

karmakaze wrote: post #17
lorean_victor wrote: post #9

Earlier quoted context omitted.

Yeah I don't think so that on its own the visual programming makes any difference (or even adds any value). The main point here is that the "visual programming" is coincidentally a solution for async programming.

The actual problem with async functions is mixing them with non-async ones. Having all futures/promises makes it easy. Now if the visual style could represent current mixed js code, that could be awesome for display and editing I'd have to try before deciding.

Yeah we reached that point pretty early on while developing the PaaS with the tool, so had to incorporate support for mixed synchronous JS blocks. you can check out how to do that here: https://medium.com/connect-platform/inline-coding-in-connect...

Re: The Problem of Async Programming, and a Crazy Idea for Solving It

#20

Post by CyberDildonics »

lorean_victor wrote: post #18
Ooolin wrote: post #6

Is the author aware of Dataflow programming ? These do give the described benefits, however, the tradeoffs are massive.

to a pretty limited degree, could you elaborate more?

You basically reinvented it, along with directed acyclical graphs and called it a 'crazy idea for solving async programming'.
Post reply on HN