Right, generally but not necessarily. There are many different kinds of visual programming languages, with vastly different pure and hybrid models, including boxes and lines like flow charts, interlocking puzzle-piece blocks without lines like Snap!, Scratch, and Nassi-Shneiderman diagrams, and grids of adjacent cells like spreadsheets and cellular automata.
Some visual programming languages use lines to represent control flow, others use them to represent data flow, and others use a mixture of both. Additionally, different kinds of control and data flow can operate at different frequencies within the same system.
Snap!, which is essentially a visual block based version of Scheme, allows you to pass functions or closures, by wrapping blocks in gray insulating "gaskets" like lambda expressions that delay evaluation, and even supports macros, special forms, continuations, user defined control structures, and threading, just like Scheme.
Another example is Max/MSP, which primarily uses lines to represent control flow and data flow. However, it also distinguishes between data flow at "simulation tick frequency" and a much higher "signal processing frequency". This means thousands of audio samples can flow along one line at every simulation tick, while only a single piece of data or signal (like a pure data-less control flow "bang") may flow along other lines at a slower simulation tick frequency.
In data flow visual programming languages, a data flow box can emit any number of data outputs at once in parallel.
A control flow box typically emits only one control flow output at a time, unless it acts like a "fork" operator. Fork operators, as seen in Petri nets, support concurrent processes by allowing multiple control flow outputs.
A data flow conditional works like a relay with three inputs (A, B, and Select) and one output. The Select input determines whether A or B is the output.
A control flow conditional, like a traditional flowchart "if", has one or more control flow inputs, a Select data input or embedded expression, and multiple control flow outputs. The Select input or expression chooses which control flow output the "program counter" branches to next.
Pure data flow networks do not have a single explicit "program counter." Instead, they typically evaluate nodes in partial dependency order, which may include loops (introducing a one-cycle feedback delay). Petri nets have multiple concurrent control flow "tokens" that flow between boxes along the lines in parallel.
Another example is Body Electric aka Bounce, which is a data flow visual programming system with relay-like data flow conditionals, but also each box has an implicit "enable" input that you can use to switch it on and off (like a power supply), so when it's turned off, the last calculated outputs are latched and buffered, and can be read by downstream dependencies, but the values are not recalculated during simulation frames when it's not enabled.
In Blender geometry nodes, data flows from left to right, while functions can be passed and applied in a way that evaluates right to left against the data flow. That is, functions are passed on the left, but the data is then processed through the function, either once or iteratively.
Functions or operations can be encapsulated within nodes and passed along the data flow. For example, a "Subdivide" node contains a function to subdivide geometry, and this function is applied to the geometry data passed into the node.
Nodes can pass functions as parameters to other nodes. For example, a "Function Input" node can be used to define a custom function that can be passed into another node, such as a "Map Range" node, which applies the function to its input data.
Functions are applied to the data as it flows through the nodes. For example, a "Set Position" node can apply a function that modifies vertex positions based on certain criteria (e.g., noise texture values).
Some nodes, like "Attribute Math" or "Attribute Vector Math," apply mathematical operations to attributes of the geometry, effectively using these operations as functions that transform the data.
Nodes can be configured to apply functions iteratively or conditionally. For example, a "Repeat" node can apply a function multiple times to achieve iterative processing, such as repeated subdivision or transformation.
Conditional nodes, like "Switch" or "Boolean Math," allow functions to be applied based on specific conditions, enabling selective processing of data based on attributes or other criteria.
While data flows left to right, some nodes can evaluate data in a right-to-left manner when applying functions. For instance, a "Function Output" node can send data back up through connected nodes for additional processing before final output.
This evaluation allows for more complex operations where data may need to be processed in multiple stages or cycles.
Another example of 'control flow' is the new behavior graph from Khronos (glTF Interactivity Specification). They did a survey of existing visual programming langauges and are trying to making a standard. It's just been released for public comment: https://www.khronos.org/blog/gltf-interactivity-specificatio...
