What you want with a programming language is to handle granular logic in a very explicit way (business requirements, precise calculations, etc.). What this article posits, and what I agree with, is that existing languages offer a more concise way of doing that.

If I wanted to program in a visual way, I'd probably still want / need the ability to do specific operations using a written artifact (language, SQL, etc). Combining them in different ways visually as a first-class operation would only interest me if it operated at the level of abstraction that visualizations currently operate at, many great examples of which are offered in the article (multiple code files, system architecture, network call).

⸻

1. Although I must confess that I have a mental block about the second and third components of a C-style for-loop and whenever possible, I avoid them if I can.

Glad I'm not the only one! Despite programming for over a decade, I still mix up the order of `update` and `condition` sometimes in `(initialization, condition, update)` for loops. Probably because I spent too much time with Python and became so accustomed to only using `for x in y` style loops.

Most visual programming environments represent programs in a static way, they just do it with pictures (often graphs) instead of text.

Perhaps there is something to be discovered when we start visualization what the CPU does at a very low level, as in moving and manipulating bits, and then build visual, animated abstractions with that.

A lot of basic bit manipulations might be much clearer that way, like shifting, masking etc. I wonder what could be built on top to get a more bird‘s eye view.

I've found "diagrams" in my head, the mental models I use to reason about a problem, are not static. They are abstract machines, with cogs and gears and clutches and input shafts and output shafts, colors and arrows and action and movement, that work like a map for finding the solution, either directly, or at least leading me in the right direction to find somewhere to easily test my map/model/diagram/machine and probably improve it if I find somewhere it's less than ideal.

The issue is, many of those are not models or diagrams I ever got out of a book or a website. They're all painstakingly, agonizingly built up over years of failure and years of struggle and troubleshooting and riding blind into the thorny thicket of an issue, blindly feeling around for a solution and if I'm lucky, integrating that into a part of my mental model.

Even something like reading XML or JSON involves a good deal of visualized movement or color to be able to parse it quickly, something that no spec or tutorial ever bothers with, if they even could.

All I know is pointers never made sense until I had a class on assembly and was able to step through my program with a view of my entire program memory open and being forced to choose addressing mode for a memory reference before it clicked. Draw all the arrows you want in a textbook, but it wasn't until I saw it moving that I understood the machine.

Same with more complex stuff like Kubernetes. Like ok, draw me a shit load of boxes with labels on them like "LoadBalancer" and "Storage" in them, but if you don't relate that to the 500 line YAML I'm told to blindly apply, I still don't have a model of how any of it works.

I don’t think we share exactly the same inner visuals, but they all relate to some intuitive understanding.

For me there are these unique and abstact visuals but they blend in with code (text) often. When I‘m intimate with a program I can often visualize line by line and fix bugs or change its behavior.

However, the things that‘s most removed from textual representation is data, memory, I/O (streams etc.) and it all moves.

Most source code is static. In case you want to show a diff, you normally do this with a side-by-side view, regardless of whether you show the diff as textual source code, or as two diagrams.

The transformations you sometime see in Youtube videos of moving and removing small bits of code to e.g. show the differences between a piece of functionality in an object oriented vs functional language are only useful because they require your eyes to follow relatively few points of interest.

Code is dynamic. It runs. The abstractions in the machine are doing things, which are changing things over time, in many different places, and it can be difficult to keep those movements all in your head without either a ton of practice, or lots of practice and some decent foundation to build off of.

Careful with what you wish for. Below the ISA abstractions there are endless nightmares of realities created and destroyed, time flowing in multiple directions, and side effects of other realities you can almost see, but won’t.

Why would that be true?

It would be much more interesting to investigate "visual first" programming where the programmer aims to author, and more importantly think, primarily in the visual medium.

What advantages would that give? The disadvantages are so big that it will basically never happen for general purpose programming. Making a brand new language make any sort of inroads in finding a niche takes at least a decade, and that's usually with something updating and iterating on what people are already doing.

The power of visual programming is diminished if the programmer aims to produce source-code as the final medium and only use visualization on top of language.

I disagree. We frequently break up large systems into chunks like modules, or micro-services, or subsystems. Often, these chunks' relationships are described using diagrams, like flowcharts or state transition diagrams, etc.

Furthermore, quite often there are zero direct code references between these chunks. Effectively, we are already organizing large systems in exactly the fashion the op is proposing. Inside each chunk, we just have code. But at a higher level viewpoint, we often have the abstraction described by a diagram. (Which is often maintained manually, separate from the repo.)

What exactly are the disadvantages here?

To me, this is the interesting avenue for investigation.

Rather than go from visualization -> code, how can we take an existing visualization that represents some underlying system (a code base, module dependencies, service architecture, a network topology, etc) and easily update the representation as the underlying system changes...

We frequently break up large systems into chunks like modules, or micro-services, or subsystems. Often, these chunks' relationships are documented using diagrams on a high level (like flowcharts or state transition diagrams etc.), but are not executable.

Fixed it for you.

Fixed it for you.

Dude, if you say the flow in the diagram is not executable, blanket in any fashion, then are you saying all of the programming projects you've been in are either monolithic systems, or have all failed?

Aka: more visual/structured medium to some use cases we use text today.

Good first step is to notice that we dont have even static data objects. Still UIs are full of them (forms) but you cannot copy paste or store them as a whole, everything is ad-hoc. Now imagine that every form could be handled like Unity scriptable object. And maybe something what prefab variants do: data inheritance.

Not necessarily, programming with visual DSL is already a thing in the field of language oriented programming. Visual programming refers to different thing, but not impossible to make a connection between the two fields.

Visual programming is now more like umbrella term for projects (and research) exploring new ways of programming beyond the textual representation. Probably better to call it non-textual programming, because some of its ideas not tied to visuality, like structural editing.

Visual programming enviraments offers a concrete way to program general-purpose code, DSLs offers a very specific language to program in a domain (language orinted programming offers ways to invent these DSLs). Often visual programming applied to a specific domain, as an alternative to textual scripting languages. Maybe this confuses people, thinking they are less powerfull, non general-purpose.

What described in the article is a visual DSL based on diagrams, using as a source for the programming itself (which is exactly the same as UML). But the whole thing are not well thought, and I think only serves the purpose of dunk on visual programming or the people how are working on them for "not understanding what professional programmers need".

My read of this post (especially the title) is the author does differentiate normally but chose to blur the lines here for a narrative hook & a little bit of fun.