The benefits of visual programming

Visual programming is one of those things that almost no one takes seriously. It's only used for teaching kids how code works at a conceptual level and serves no purpose outside of this. Wanna write real code? Use a real programming language. Even intepreted languages are held in way higher regard than visual languages.
But should it be this way? I think not.

Aside: The data structure of programming languages

We can typically reason about programming languages in two ways:

• A stack of operations evaluated from top to bottom
• A graph of operations with nodes being evaluated as they are reached

For example, here's a program that evaluates (10 + 20) * 5:

Both visualizations have their use cases. The stack is how your CPU sees code. It simply runs the first instruction and then moves onto the next.
In the stack model any code earlier in the program may have pushed or popped arguments that we need to worry about. The graph while looking more complex at first is easier to reason about. If we know the add instruction expects two arguments we can easily verify the programs correctness by checking how many nodes are connected to the add instruction. Another benefit of the graph is that we can easily rewrite nodes without the rest of the program having to worry about it. For example the (add 10 20) node can be swapped out for a 30 node. In the stack you'd have to shift all the operations up or down after making modifications.

How text-based language compilers works

Pretty much all compiles follow these steps:

1. Parse the written code (abort on syntax error)
2. Create an abstract tree representing the parts of the program (structs, functions, expressions)
3. Resolve references (abort if a symbol can't be resolved or the types don't match up)
4. Optimize
5. Ouput assembly

A revelation

Steps 1 through 3 are only neccesary because we decided to program in text-based programming languages. In visual languages correctness is evalutated not only at compile time, but during the entire process of development. It is literally impossible to create in incorrect program in a properly sturctured visual programming language.
While parsing isn't that hard, resolving references takes a significant amount of time in traditional compilers since you're essentially comparing one symbol with all the other symbols in your program to see what it's supposed to refer to. In visual languages the compile process essentially becomes a one to one mapping if you skip optimizations (which isn't unusual for development builds), essentially making it trivial to have "instant" compile times. There are many other benefits to visual programming:

• Trivial static analysis
• Trivial refactoring
• Trivial intellisense
• Minimal complexity for the programmer, it's all just nodes with inputs and outputs

All at zero runtime performance cost!

Existing visual languages suck

It's true. There's no denying it.
Why is this the case? I have no clue. I find it hard to believe that no-one else has considered the idea that visual languages might serve as a genuine alternative to textual ones. What I can do is list off some things the existing languages get wrong.

• Interpreting the graph as-is instead of compiling to machine code, causing the program to be slow
• Transpiling to source code of another strongly typed language, bringing back long compile times
• Having users manually lay out nodes instead of introducing some automated system
• Forcing users to write low level code using ginormo nodes (10 + 20 *(30 / 3) + 2 becomes a huge collection of nodes that fills the entire screen)
• Jamming everything into graphs even when stacks are obviously more suited for the job
• Being mostly mouse-based instead of letting users navigate by keyboard

Downsides of visual programming

There are some real downsides to visual programming that can't easily be solved.

• An advanced editor is required to work on projects
• The project is stored in some format most people will never bother to understand, if something gets corrupted the entire project becomes unusable.

Though it should be noted that these same downsides apply to all IDE-based workflows. On top of these downsides, it's not great for every domain. I mostly believe visual languages shine in "event driven" domains where certain modules should react to other modules' state changes. Think high level game scripting and web apps for example.
I'm interrested in exploring the visual programming space more thoroughly in the future to see if I can actually make any of these claims a reality.