random memes }

Subtext - and alternate representations of program structure

Alarming Development » Blog Archive » Alice in Subtext-land "Let’s face it: syntax is a simple and intuitive way to represent structure. But a fundamental principle of Subtext is to avoid syntactically encoding programs so that their semantics are explicit and immediate. It should be possible to use syntactic techniques as a visualization in the UI instead of as a representation of the source."

Like a lot of other software folk, I find the attempts at "Visual Programming" intriguing ... but not always compelling. It sure seems like there should be a better representation for programs that would accelerate the development process ... but no one has yet come up with anything useful.

Jonathan Edwards is taking another run at this problem. I wish him luck. Parts of the offered demo are compelling ... and other parts less so.

The example data based execution, live/dead code highlighting, and presentation of intermediate values is all rather interesting. I can't help but feel the difference between program text and the in-memory form is over-stated, or at least mis-stated. On current machines translation from text to in-memory form (and back) takes a very small fraction of a second - not a significant chunk of time in the development process (unless repeated far more often than truly necessary).

At one point in the demo, as an aside, Jonathan says he might actually write more test cases, given the illustrated dynamic evaluation against example data. It was meant as a joke, but perhaps this is a clue. The graphic representation of low-level program structure might not be (usually) compelling, but the ability to evaluate against example data - and minutely inspect the evaluation - might be very useful indeed.

Eh. This is more of a brain-dump than a hard-edged outline. I see both graphic and textual forms as alternate representations of the same underlying program structure. I do not see either form as exclusively superior. Reading program source to puzzle out the inputs (values read) and outputs (values changed) is tedious and error-prone. Flipping the representation to a form that makes the inputs (and where used) and outputs (and where changed) could be a big boost. Maybe the graphic form is more useful at a larger granularity (for composition and presentation of structure), the text form the compact detailed view, and the minute graphic form for the rare occasion when a detailed view of an example computation is needed.