Now dataflow programming languages, which are often visual, are naturally parallelizable in the same way functional languages are, but this is not related to their visual implementation.
Now dataflow programming languages, which are often visual, are naturally parallelizable in the same way functional languages are, but this is not related to their visual implementation.
The small is type systemic. Machine proofs show that you have written your typable logic correctly.
This is still not at the level of concurrency or machine assistance to which I am referring.
You are getting closer with dataflow programming languages. Pipeline and compute farm visualization, spatial/resource quota policies and control, and process calculi equivalences proven across visual/spatial refactorings is what is needed.
Of course you can do all of this with a linear byte array. Of course you can get more dimensions with names and references.
Unfortunately, these methods are very specific and very technical and, despite their accuracy, are relatively devoid of meaning at-a-glance. In the future, a domain expert will work with a programmer to build an application which the domain expert will then operate and monitor. This is not possible without heavy use of graphical interfaces and visual representations. This is not possible without an advanced type system and an easily constructible syntax for DSLs and DSL graphical front-ends.
Perhaps you wouldn't classify this as a "visual programming language" as most of the programming itself is not done via virtual objects and connections. However, visual system tools will become increasingly important as programming moves from implementation to specification and control.
This has been in the future for at least 30 years, by my knowledge of the literature. In fact, it's been in the future for so long by now that it seems to be in the past, by my reckoning.