The Problem of Async Programming, and a Crazy Idea for Solving It
1–10 of 25 posts
Re: The Problem of Async Programming, and a Crazy Idea for Solving It
#2Yes, because XML is too old to us.
Re: The Problem of Async Programming, and a Crazy Idea for Solving It
#3Yes, because XML is too old to us.
and to be fair its a really redundant format. I mean I personally would prefer the current undesirable situation rather than doing XML-based coding all day.
Re: The Problem of Async Programming, and a Crazy Idea for Solving It
#4I 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:
doA: doC doE
doB: doD doE
doC: doE
doD:
doERe: The Problem of Async Programming, and a Crazy Idea for Solving It
#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);
The difference is in the "do" functions themselves: they would be async (meaning they return a promise, and they accept promises as parameters).
Re: The Problem of Async Programming, and a Crazy Idea for Solving It
#6Is the author aware of Dataflow programming ?
These do give the described benefits, however, the tradeoffs are massive.
Re: The Problem of Async Programming, and a Crazy Idea for Solving It
#7Doesn'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?
Re: The Problem of Async Programming, and a Crazy Idea for Solving It
#8Callback 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))
const [a, b] = Promise.all([doA(), doB()])
doD(b)
const c = await doC(a)
doE(c, a, b)
Re: The Problem of Async Programming, and a Crazy Idea for Solving It
#9Doesn'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.
Re: The Problem of Async Programming, and a Crazy Idea for Solving It
#10Callback 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.