[pacificmint]

I realized at some point that when people at work draw on whiteboards it usually ends up as boxes and lines between boxes.

But after thinking about it, it feels natural, because usually we talk about "Things" and the "Connections" between them.

Could be a companies org chart, a family tree, a network diagram, abstract things like processes. It's all "Things" and "Connections".

Maybe that's why graph theory has so many applications. Because at the end, it's all just graphs with vertices and edges.

[Bost]

> Because at the end, it's all just graphs with vertices and edges.

That's not the end. At the end there are just objects and morphisms between them. Graphs (with their edges and vertices) are just a special category of... Well, have a look at "Category Theory".

[ninetyninenine]

Well programming itself with text doesn't have boxes and lines. So there's other isomorphisms to represent this concept.

[TeMPOraL]

Of course it is. At a low level, AST is lines and boxes. So is a trace of control flow over time.

Code is downstream of thinking, which makes it downstream of lines and boxed.

[ninetyninenine]

The ast is just the result of a technique for parsing one style of programming involving text.

Visual programming with say boxes and lines at its core should not involve an ast.

You need to think outside the box. Your thinking of textual programming as the core and the visual programming as an abstraction above it which is how the industry has been focused since its inception.

[sen]

Programming is the lines, and the boxes is the data you’re working with (generally).

[DonHopkins]

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.

https://en.wikipedia.org/wiki/Nassi%E2%80%93Shneiderman_diag...

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.

https://snap.berkeley.edu

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.

https://en.wikipedia.org/wiki/Max_(software)

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.

https://en.wikipedia.org/wiki/Petri_net

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.

https://donhopkins.medium.com/bounce-stuff-8310551a96e3

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.

https://docs.blender.org/manual/en/latest/modeling/geometry_...

New Blender 4.0 Loops!

https://www.youtube.com/watch?v=mr_nQBoJPXw

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.

[kevthecoder]

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...

[yunohn]

Programming, especially imperative, is essentially boxes (statements, function calls) and lines (control flow). That’s why algorithms can be represented as flowcharts.

[ninetyninenine]

Right. I call it an isomorphism. You can translate one into the other and back. Whatever "other" form of programming exists it can and should be translatable to boxes and diagrams.

But this "other" form on first glance can look very different. There are no boxes and lines in C++ or python for example.

[PakG1]

Sure, but code has a level of complexity that boxes and lines abstract away. If you want to describe a certain level of complexity, you'll need code or something that achieves a similar level of capability. If you don't need that high level of complexity, often because you're abstracting complexity away, it's hard to find an alternative that isn't better than boxes and lines. If there's a better alternative, nobody's found it yet. Boxes and lines appear to be a final state to which all roads lead.

[yunohn]

I think you misread my post. Why would C++/Python not fit my description? Which languages do you consider?

[ninetyninenine]

No. I did not misread. I believe you misunderstood.

You’re saying c++ and python fit into a category of programs that is foundation-ally really just boxes and lines.

I’m saying that’s not the right way to look at it. Because you can make the opposing statement. You can say that programs that are boxes and lines are foundation-ally just text programs.

So because both contradictory statements can be made both aren’t really correct. There is no hierarchy. Boxes and lines is one concept and textual programming is another peer concept standing on equal footing. Both are isomorphic and thus translatable to each other.

The point of my post is to suggest that there are other concepts that occupy this equivalency space. Imagine a category of interchangeable interpretations of programming that are all translate-able between each other with no hierarchy. It’s similar to the space of human languages. All human languages don’t occupy a hierarchy yet all are isomorphic.

[mejutoco]

One can also think as an assembly instruction as origin and destination (line) and an operation (instruction).