The simplist thing that we could do to bring about visual programming, is to simply take our existing C programs out of files, and assemble them on a plane. Without changing any of the language– just use the ability to resize the text, to color it, to spatially position it. Make one function’s implementation very large, make another’s very small. Where there is an object, bring all the functions together in one cluster. Make the most important functions large, and position them prominantly. Where there are helper functions, position them next to the function (or functions) they assist. (Also resize them to be tiny tiny, so that they don’t distract the perusing programmer.)

Make the debugger jump the view around the visualization. This way, the programmer sees where they are “in the big picture” (literally.) They will then understand very quickly, very intuitively, where they are in the software.

Functions of little to no significance will be clear, because they will be (literally) little. Functions of great significance will be clear, because they will be (literally) large.

The spatial relations that the programmer envisioned in his or her head will be preserved on the screen, and the intuitions that they embody will become the intuitions of the debugger.

If you wanted to get really radical, (I am being facetious here,) you could allow for lines and arrows, so that we get a step closer to schematic. You don’t have to make them functional; They could be purely decorational – like a documentation comment. It could dramatically increase the expressiveness of the program.

What this goes to show is that “visual programming” does not require great leaps in order to prove its usefulness to doubters, naysayers, and skeptics of all thing visual. (Fortunately, a dying breed, it seems these days– Visualization has grown in recognition since, say, 2005. Before, it was lampooned as an evil concocted by a sinister force called “marketing,” 1 and the Command Line was literally compared to the Word of God. 2) We don’t have to make entirely new languages composed out of icons; We don’t have to throw out text as a concept. Just take existing text, and be able to position it, to scale it, what have you. This is the power that RobertHorn? calls, “shape.” It’s not about boxes, triangles, and ovals; It’s about position.

See Also



great idea. Just like who knows how many other people, i’ve always thought of visualization + programming languages as having to do with machine-readable semantics, and then immediately put the thought on the back-burner because i haven’t yet been shown a set of machine-readable visual semantics that i think is better than text in all cases. but now that you mention this, it seems so obvious, thanks for opening my eyes. i suppose people will add visualization to existing programs, written in existing languages, SideSystemsFirst, with separate source code annotation documents that describe layout so that people who don’t like the visual stuff can just ignore it.

A minor quibble with “…It’s not about boxes, triangles, and ovals; It’s about position.

  • Postion, or more precisely (relational) position is one valid “dimension” or “distinction” of several possible ones; just as are scale, font, or the other “decorations” (e.g. color, etc). Let’s not (arbitrarily) clasify things as being different or the same. Instead, I think we have an adequate appreciation of logic and mathematics to define some precise distinctions to which we can then assign specific differentiating meanings.

Yes, good point. I found articulation of “shape” in RobertHorn?’s taxonomy to be confusing, until I realized, “Oh, he’s not only talking about geometric figures,” he’s talking about much more than that.

This language is possibly related: SNUSNP. An idea from it for visual programming in general:

  • Control flow: the “path” of execution can be literally a “path” in the space of the source code, displayed explicitly (like in flow charts)
    • in addition to(or even instead of) to passing control to a function by referring to it by name, one can draw a line between the function call (or GOTO, etc) and the function definition (or GOTO target) (like in flow charts)
      • a problem with this is that functions that are called from many different places will have a zillion lines clogging its entrances and exits, and these lines will either have to stay separate within the function, adding more clutter, or they will merge, which is incorrect
        • just like how in IDEs you can “fold” code for functions that you are not currently looking at, you should be able to hide execution paths other than the one you are currently interested in
    • conditionals have a fork in the execution path. the “then” and the “else” don’t have to be written underneath the “if”, they can be off to the side or whatever, provided a line connects both of them to the “if” (like in flow charts)


1. I find it difficult to prove this historical fact, but a review of Dilbert comics may provide a starting point.
2. “In the beginning, the Command Line,” by NealStephenson.

Define external redirect: RobertHorn

EditNearLinks: NealStephenson