If BizTalk has it, why shouldn't my visual programming tool have it?
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.
See JSONLogic UI for similar implementation: https://github.com/GoPlasmatic/datalogic-rs Disclaimer: I am the maintainer of the datalogic-rs project
... everything evolves until it can read mail^H^H^H becomes Turing complete?
> 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 :)
Are there any exceptions?
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.
If you're curious how out of control and wacky these sort of graphs can get, https://blueprintsfromhell.tumblr.com/ has a bunch of fun examples.
https://dev.epicgames.com/documentation/unreal-engine/bluepr...
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.
Also, the general question is who is the target audience: It seems pretty obvious to me that programmers who live and breathe code wouldn't be very enthusiastic about visual programming. But that might be different for other professions that don't have that kind of coding expertise.
Also, a lot of programming skill is about keeping the logical abstractions and runtime state in your head that your code will create - not so much reading what is on the screen. That's far easier if you have written the code yourself than if you have to get familiar with existing code.
Thanks to agents, the second case is becoming the dominating situation now, so clever visualizations that help you make sense of existing code and its runtime state might be in demand in the future.
Later systems added to this by being programmable with structured text.
The first time I came across a system that was programmed entirely with relays I was completely blown away by what was possible. And also by how heavy, noisy and power-hungry it was for a portable device.