You certainly don't make each processor or core a dimension if that is what you are suggesting. The small is type systemic. Machine proofs show that you have w

You certainly don't make each processor or core a dimension if that is what you are suggesting. 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.