Visualizing Software Designs
In this interview, James Gosling claims that code would be more understandable if it wasn't restricted to plain-text ascii layout. For example, maybe you want to see your code as rich mathematical notation, or as rectangles that represent database tables.
I think this is a good idea as far as it goes, but it misses the real meat of what makes programs difficult to understand. The real problem is that programs are indirect -- they manipulate values that are known at runtime, but are not visible anywhere in the code because the code only shows the static parts of the program. For example, if I'm using a linked list, I won't see anything resembling a series of boxes connected by "next" pointers. At best, I'll see a class definition for a single node, which contains a single next pointer. The only place I'll see an actual list is in my imagination.
This is related to what I was talking about in Put it in the Syntax. The idea of that post was to try to make the runtime behavior (and runtime structure) of the code visible in the syntax itself. If you can remove the separation between static code and dynamic values, programs will be clearer and easier to understand.
I think that if we restrict ourselves to making fancy representations of the AST, without bothering to consider what information is actually in the AST, then we will fail to make the programming task any easier for the average person.
In my head, the fact that programs are static while what they manipulate is dynamic reminds me strongly of dynamical systems -- a.k.a. chaos theory. For example, the static equation for the Mandelbrot set is simple: Z <- Z2 + C. But the dynamic behavior of that simple equation is very very complicated. Having an IDE do syntax highlighting on the static equation won't help you understand the Mandelbrot set at all.
Posted on November 11, 2003 12:15 PM
More languages articles
Interesting you'd mention the Mandelbrot set. I was just playing around with the set and Mathematica (speaking of rich equations in code :-). Looking at the equation Z_{n+1} = Z_n^2 + C doesn't really help one understand it.
However, graphing the complex vector field of Z^2 did help me understand it. And that's a static part of the dynamic system. That field was capable of showing how things moved in one specific case of the system, and it was enough to help me grasp the dynamics as a whole.
I think programmers could learn a few things from mathematicians. Look at tensor algebra. It has two separate syntaxes (or syntaxen). One for representing tensors themselves, which helps you understand how they're layed out, and one for working with them in a declarative way. If they wrote those procedural sigmas with limits all over the place, you'd never understand what the hell is going on. But Einstein summation allows you to say Aik = BijCjk. That doesn't look like what it's doing, but rather what it's saying. And moreover, it's convenient to work with.
Haskell did this, too. You write lists in Haskell [1,2,3], which looks an awful lot like a list. But you work with them in head:tail form, which allows a declarative statement about the relationships between the elements. This is brilliant, and it allows for very clear list processing.
The MSV* suite's half way there. You "declare" forms in a visual, representative way. That is so amazingly nice. But working with them is still awkward and procedural. Dataflow techniques are needed here -- but they don't look anything like forms. It's a convenient notation/semantic.
And that's where we need to go in more domains. Representative literals; convenient operations.
Posted by: Luke Palmer at November 11, 2003 02:29 PMAlistair: Small world. I went to college with Paul Cantrell (Eidola is his project), and for a while hosted Eidola.org out of my closet (when it was Slashdotted (all text -> no problem!))
Anyway, with current models representing dynamic status while you're writing the code is analogous to the halting problem. You can't know what things are going to look like until you run the code. Similarly, you can't say whether an arbitrary point is in the Mandelbrot set without doing an unknown number of calculations.
When you're writing the code it is static. It's only when you run it that it becomes dynamic. To show the dynamic structure of the program, you have to merge write-time and run-time, which sounds to me like all the scriptable software's "record macro" function, which is indeed a whole set of programming tools and "languages" which are intended to (and are successfully) used by 'non-programmers'.
Generally these don't let you get very abstract with your operations though; the scope of the languages are limited to a narrow concrete set of operations. Maybe if you feel too limited, you can go and manually edit the vbscript or whatever was generated, but that's clunky and only available because the tools to generate script in the first place were inadquate.