Speaking of using color as a formal syntax in a graphical programming language. The example found at http://www.coretalk.net/CubiconPrivate/CubiconPaper/MemoryMa... (User: Cubist1 and Password: Sandy2) is the executable design of the Memory Manager module for a next-generation virtual machine (VM). The visual directory on the left of the screen is a number of control-flow methods, interleaved with white and gray backgrounds. The colored icons express fundamental language constructs, in this case, memory pointer transfer, comparisons, and the like. This set of methods compiles into 37 KBytes of ANSI C.
True enough, LabView visual 'code' doesn't scale cleanly. One of the reasons for this 'spaghetti' is that the language combines control-flow and data-flow constructs in the same schema level. However, LabView remains the most successful graphical language to date, leaving MUCH room for future language innovations for those who dare to journey out of the scripting realm for software expression to deal with the scaling and many other engineering issues for a new paradigm.
Alan Kay and others pioneers brought us object-orientation almost 40 years ago now, a set of organizing abstractions to enable people to conceptualize systems that could map to real world domains. What if there are even a higher order of abstractions that could place systems into semantic contexts? Perhaps this is where graphical abstractions could be useful to manage this complexity through visual constraints, thus transition the software engineering 'art' towards a true systems engineering 'discipline.' What fundamental properties restrict software engineering from such higher order tool evolution considering that visualizations have been applied to virtually every other scientific, business, and art domain?
Jonathan Edwards of MIT's CSAIl published a Manifesto of the Programmer Liberation Front a while back that makes an interesting case for exploring alternatives like graphical programming for replacing text-only languages.
