What's Wrong With Visual Programming?
 

Nobody uses it.

Graph-grammars and graph-rewriting system, often expected to be miraculously powerful, are theoretically well-founded and have been studied thoroughly in the last few years. There are several graph-rewriting rule paradigms to chose from, and a number of graph-oriented environments have been written, sometimes with considerable effort. (The Aachen PROGRAPH environment contains 400,000 lines of C code.) They exist; they're free - why don't people use them?

Clutter

The idea behind visual programming is to harness the powers of (mostly two-dimensional) visualization and interaction to help people understand and write programs. The connections which, in a regular linear programming language, are made through word identity (a function call and a function definition use the same word and evoke similar concepts in the reader), shall now be made by visual means - by drawing a line between connected items, or by putting things next to, or inside, other things.

But, far from being immediately understandable to even novice users, the straightforward application of the graph paradigm is a confusing mess. Why? Unsuprisingly, little pieces of text in boxes with arrows between them are just as hard to interpret as little pieces of text without boxes and arrows, except that they take up more space, and have visual clutter around them that distracts from the meaning of the text.

Even when one kind of arrows-and-boxes are replaced by normal, "bold" and dashed arrows, boxes, boxes with round edges, oval boxes, oval boxes with three kinds of lines behind them, boxes dented inwards, boxes dented outwards, and boxes with the upper left corner folded in - even then, the visual "alphabet" that this constructs is far less efficient than the alphabet of words that we have grown up with.

Overemphasizing syntax

Many computer science texts underline keywords or print them in a bold font. Beyond the ``typographic sillyness'' that [Pike89] observes, this convention emphasizes simply the wrong kind of information; after the first few days of acquainting oneself with the programming language, syntax fades into the background. The important words are not the keywords, but the user-defined names, the variables, types, and functions.

Most visual programming environments suffer from that exact same disease, only more so. They use their visual power to emphasize the syntax of the programming language, instead of helping the user to express their ideas.

User-defined types can become syntax, and user-defined functions can become keywords, once one has gotten used to them. They vanish as problems; they become means to achieve a higher goal, and very little cognitive effort is expended to parse them. For visual programming, this means that the user must be able to easily specify visual primitives, not just combine existing ones.

No input device

When Engelbart invented the mouse in '56, he ruined graphical input for generations to come. You can't draw with a mouse. Instead of exercising the fine motion control and sensitivity they're laid out for, the fingers of my right hand rest useless on an unergonomic rectangular pad, with even less to do than when I'm typing on a keyboard.

Sure, I can call up a paint program with an unlimited number of line thicknesses, fonts, and geometrical figures, can draw brush strokes with any bevel shape I like, on any background pattern I like, with any color I like, and run the result through any number of image processing primitives.

But the results aren't sexy, they don't have that swing that any old handwritten doodle has. They're not personal. It is fun to draw; it isn't fun to draw with a mouse.

So, why bother?

The same computer scientists that condemn visual programming for its obvious faults still draw when they design. I believe the nicest thing about squiggles is that you don't have to name them. You can just draw them next to each other, and connect them with a line, and if the line later turns out to actually connect a lower protocol layer deep inside squiggle one with something entirely else in squiggle two, so be it. Squiggles are modest; they don't have to mean something all the time.

This meaninglessness makes drawings ideal for the development of meaning; they don't crowd on those who see it. Starting with squiggles, annotating, animating them, slowly fleshing out the missing parts - that would be a great system to have. Make images first, then make rules.