Interesting take on "visual abstraction" vs "visual representation" (if I may add the wording), where Drakon represents the former and Flyde the latter.
I'm uncertain to what extent visual _representations_ of real code has anything to offer developers as a target group. I think it's the strive to have FBP represent already human-friendly code that gets in our way of thinking.
At the end of the day I want to define and execute logic without having to approach parallelism and asynchronicity as programming concepts. Instead the paradigm should transform such challenges into spatial ones. Instead the paradigm should transform such challenges into spatial ones. (Yes I wrote that twice for effect.)
I have yet to see such a system, but Drakon comes close.
I like the "visual abstraction" vs "visual representation" distinction, and agree with your point that Flyde falls into the latter.
Regarding parallelism and asynchronicity, Flyde manages to answer that need. You simply connect 2 nodes in parallel - for example - https://imgur.com/a/GJewFHd this fetches data from 2 apis, maps them and collects them into a new object. It's low-level for sure, but parallelism and asynchronicity are completely spatial. Do you mean it in a different way?
That way, yes. I mean a transformation into spatial problems in much the hardware design way, e.g. the "I need to find a way to add that node without crossing any wires" way. Your example is surely elegant for Promise.all(), although it's a happy path. Can users manage rejected promises, Promise.any() or Promise.allSettled() through nodes and wiring (i.e. not through hidden configuration)?
I think so, yes.
A rejected promise is equivalent to a node that throws an error. Flyde exposes a default "error" output pin for each node. As everything in Flyde is async, any error thrown can be viewed as a rejected promise.
Promise.any can be achieved with 3 promises and a throttle node
Promise.allSettled translated to connecting the error output pin and hooking it to whatever you wanted the fulfilled value to go.
I'm uncertain to what extent visual _representations_ of real code has anything to offer developers as a target group. I think it's the strive to have FBP represent already human-friendly code that gets in our way of thinking.
At the end of the day I want to define and execute logic without having to approach parallelism and asynchronicity as programming concepts. Instead the paradigm should transform such challenges into spatial ones. Instead the paradigm should transform such challenges into spatial ones. (Yes I wrote that twice for effect.)
I have yet to see such a system, but Drakon comes close.