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.
That is an interesting framing. I think the "maker vs taker" label is great. Creative Inc[0] uses "suitcase handles" to describe something similar but more generic.
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.
[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!
I've found that while people don't want to change out of Excel they are forced to by the size of new files. The more data is generated by computers, the less likely it is to fit in Excel
I imagine many professions won't be able to use Excel in 10 years based on this trend.
If you are operating under the "sports team" analogy, you should fire them. If you are operating under the "we are a family" analogy, you should find reduced roles where they are useful. Different organizations choose different base analogies but it is easy to tell which one you are in.
We would love to understand what went wrong so that we can keep improving the integration experience. If you are interested in talking to us, please email me at [email protected]
https://ouros.energy/