sbensu

That last point is super interesting: these diagrams never tell you much about the implementation or how it would perform.

The distinction you are making is right. All those examples are examples of visualization, not of direct programming.

But why can't we use what today are visual representations of the programs as the actual programs? Can't we have the state transition diagram that today is a visualization of the code _be_ the definition of the state transitions? That is the question the post is asking

In other words, elevate the visualizations that we already use into programming, instead of programming with visualizations we don't use.

[post author] You are right. Any "language" visual or other wise used for communication has to include the level of detail trying to be communicated. In the Rust memory layout example, Rust syntax doesn't spell out its memory layout in Rc<T> definitions.

The point though is that the two users of the language _decide_ to communicate in a visual representation! Why is that?

They could spell it out in text, adding that lower level to the text, and yet they don't. That is a sign the users are thinking about it visually and the visual representation maps better to what they hold in their head.

You are right. You can see the data first, charts, even dependencies. And yet nobody is drawing `IF(ACTIVE[A1:A4]=E$1)`

Amazing, thank you for taking the time

Nice!

That sounds super interesting!

Did I understand correctly that the additional complexity came because you needed to emit optimal assembly? Or was implementing the logic from the state machine complicated enough?

You are right. The diagrams are used as explanations not as the source of the program. But wouldn't it be neat if when you sketch out the state transition in a diagram (how I think about the state transitions), _that diagram_ was the source of truth for the program?

That is the implied point: let's go to places where we already draw diagrams and check if we can elevate them into the program

[post author] I am familiar with those and have used a couple. There are similar examples in music, where visual programming dominates.

The implied audience of this post (not clear) is people writing business applications, web dev, etc. The examples are picked to reflect what could be useful to those developers. In other words, all the examples you mentioned are great but they are not how a "software engineer in a software company" does their job.

Those two are both primarily for real time signals and music right? That is a great domain for wires, transforms, and pipelines.

Have you ever seen them used in a different context?

It is certainly possible and that is how most of these visual languages do it. But is that how _you_ want to program that logic?

Thank you! Should be fixed in a minute

[post author] I agree. On many domains you can find a great mapping between some visual representation and how the developer (beginner or not) wants to think about the problem.

I personally don't see any one pictorial representation that maps to a general programming language. But if someone does find one, in the large and in the small, that'd be great!