Hacker News Reader

Comment by mynjin | Hacker News Reader

Eh, I guess slapping some literal, variable, and operation nodes together makes it visual, but I don't think it makes it easier.

Contrast with something like Scratch which is useful because it helps prevent typos, clearly presents expected arguments, and creates snap connected chains of logic.

Even better, contrast something like Drakon which offers visual abstractions such as skewers, happy paths, silhuettes, common fate, etc.

I really like the concept of visual abstractions. Nodes are abstractions but I don't think they are high enough level to improve over text. And I think text will always be awesome even if it is assisted by better ways to animate and visualize logic and systems.

Also, can I grep over Flyde? I'd hate to lose that basic ability.

Drakon: https://drakonhub.com/en/drakon

View on HN

This is something I ponder about a lot.

For those proficient in writing textual programs, a tool such as Flyde as-is might provide value by enforcing modules to be stand-alone and well-defined; the premise of https://en.wikipedia.org/wiki/Flow-based_programming as a paradigm that promised value even without using a visual editor, and just by adhering to the concept.

But for those who lack the understanding of coding syntax and grammar, a visual tool, even in a not-much-higher level of attraction, could make all the difference. I've personally mentored dozens of entry-level developers many struggled with concurrency and asynchronicity. (callbacks, promises, etc). these are concepts that become a no-brainer using a nodes-and-wires editor.

Regarding prepping - fair point. I'm sure it's not what you meant, but here's a grep in a Flyde flow (the second example) - https://imgur.com/a/V9u1ETl

Thank you for your reply. I'm usually skeptical of visual paradigms but I'm not trying to be critical.

Looking at flow-based programming, it looks like it could help in visualizing and understanding asynchronous systems that wouldn't be so intuitive from a code listing. In that way, I suppose it would force a functional style as well. So maybe good for gluing those parts of one's apps together.

I did look at the code examples; attributes and code wrapped in json. Obviously greppable, but then if one expected a learner to grep, version diff, author tests?, linting?, etc. they still must dip into and learn regular dev tools. I don't know if Flyde is supposed to eventually subsume that other functionality or if it is a higher scripting layer used in conjunction, and so must eventually be learned anyway.

Or is Flyde just trying to introduce an easier coding path in order to bypass the more superfluous parts of software dev such as tabs vs spaces, editor choice, oop vs functional vs procedural vs whatever.

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.

Reply on news.ycombinator.com