A key feature about data-flow programming that seems too often missed is that it is (or can be) hierarchical.
Define a subgraph of atomic nodes as itself a node with its ports formed from as-yet unconnected ports of its atomic constituents. Compose yet higher subgraphs of subgraphs and atomic nodes. Package all this in some way.
This is directly analogous to syntactic programming where functions aggregate other function calls and all that packaged into a library with an API.
Technically, it seems to have three different paradigms that it exposes:
> Procedural/Event-based/Declarative - These three snippets achieve the same thing in different ways. One repeatedly asks the button if it is pressed; one tells the button to control the LED; and one tells the LED to follow the button's state.
Much of the article seems to focus on the latter "Declarative" way, which they created a Node-RED-like UI for, which is indeed flow-based. But other approaches seemingly can be used too :)
I don't know, "node-based" interfaces as a concept seem to have made inroads into quite a number of (specialized) fields, e.g. image processing or movie postproduction.
My takeaway is that simply visualizing the AST of a procedural language doesn't do much in reducing the complexity and just makes it harder to read or edit long programs.
In contrast, visualizing data flow graphs can have real utility.
I think PLCs are programmed using a mix of text and visuals. Or at least that's what I remember from uni. I'm not entirely sure why that is. I suppose it makes it a lot more obvious to your coworkers and management when you make spaghetti code, which I suppose can create pressure to not make a total mess of things.
Houdini (VFX/3D tool), virtually unchallenged in some of its domains, it's basically visual programming. Very basic what you'd do inside of Houdini when working with it (with screenshots): https://www.sidefx.com/docs/houdini/basics/intro.html
Unreal Engine also have "Blueprints" for game logic that remains fairly popular, maybe not always as the underlying systems, but at least as a control surface for game designers, like a "API" kind of.
This is amazing work. I've used GPIOZero in my RPi projects before. In the future, you can introduce conditional operators in the flow. It can become a complete coding platform.
the problem is every visual programming tool eventually reaches the point where you need a 'code node' and then everyone just writes code
A key feature about data-flow programming that seems too often missed is that it is (or can be) hierarchical.
Define a subgraph of atomic nodes as itself a node with its ports formed from as-yet unconnected ports of its atomic constituents. Compose yet higher subgraphs of subgraphs and atomic nodes. Package all this in some way.
This is directly analogous to syntactic programming where functions aggregate other function calls and all that packaged into a library with an API.
I am totally pressed. What now?
FYI, the general paradigm here is named flow-based programming (FBP):
https://github.com/flux-doctrine/awesome-fbp
Technically, it seems to have three different paradigms that it exposes:
> Procedural/Event-based/Declarative - These three snippets achieve the same thing in different ways. One repeatedly asks the button if it is pressed; one tells the button to control the LED; and one tells the LED to follow the button's state.
Much of the article seems to focus on the latter "Declarative" way, which they created a Node-RED-like UI for, which is indeed flow-based. But other approaches seemingly can be used too :)
Somehow these visual programming tools never seem to get much traction.
Are there any exceptions?
I don't know, "node-based" interfaces as a concept seem to have made inroads into quite a number of (specialized) fields, e.g. image processing or movie postproduction.
My takeaway is that simply visualizing the AST of a procedural language doesn't do much in reducing the complexity and just makes it harder to read or edit long programs.
In contrast, visualizing data flow graphs can have real utility.
I think PLCs are programmed using a mix of text and visuals. Or at least that's what I remember from uni. I'm not entirely sure why that is. I suppose it makes it a lot more obvious to your coworkers and management when you make spaghetti code, which I suppose can create pressure to not make a total mess of things.
Houdini (VFX/3D tool), virtually unchallenged in some of its domains, it's basically visual programming. Very basic what you'd do inside of Houdini when working with it (with screenshots): https://www.sidefx.com/docs/houdini/basics/intro.html
Unreal Engine also have "Blueprints" for game logic that remains fairly popular, maybe not always as the underlying systems, but at least as a control surface for game designers, like a "API" kind of.
node-RED for PLC programming
Is that really used professionally?
Blender shaders maybe?
This is amazing work. I've used GPIOZero in my RPi projects before. In the future, you can introduce conditional operators in the flow. It can become a complete coding platform.
See JSONLogic UI for similar implementation: https://github.com/GoPlasmatic/datalogic-rs Disclaimer: I am the maintainer of the datalogic-rs project
Hi ben :)