SubText (ThoughtStorms)

Context : LanguageOrientedProgramming

A ProgrammingLanguage by JonathanEdwards which is also a tree-shaped StructuredDocument.

Quick summary / notes

: (but why not both? Isn't that what TedNelson's ZigZag is about? A general linked cell structure which can be organized like a spreadsheet plane or a tree or a list etc.)

(Obvious) thought ...

: Could it be more wiki like? With a tangle of TransClusions (or pipes) between different wiki pages? Less emphasis on expanding / collapsing, more on jumping between pages.

: also, I'm not that excited by drawing the links as lines, the important thing is to be able to follow them.

: but I'm fascinated by the way everything is just document structure.

: recently I've been thinking whether there could be a language like a syntactic variant on LispLanguage which used nested bullet-point lists and other WikiMarkup-like syntax to represent list structure etc.

: something that looked like wiki but worked like Lisp.

: once again the attraction is a mixture of code / data in the "same language"

: and a kind of LiterateProgramming (embedding code in text)

: is this actually very similar? Every function call is an "include" of something in another part of the document. When it's expanded, the substitution would be very like a function call.

Compare SmartAscii

Now I'm feeling more sceptical :

I can't understand why Edwards is so critical of "text".

Surely text is a stunningly flexible and expressive language for communicating with the computer. There are maybe 40 - 50 characters which can be endlessly recombined in strings of indefinite length. We can often describe powerful, abstract ideas very concisely. And it's readable and writable and editable in the same medium.

On the other hand, the SubText demo seems to want to replace it with :

a) a certain number of gestures eg. drag and drop an element, mouse click on an element to transform it's appearance with some syntactic sugar, etc.


b) some graphical cues, such as lines drawn between elements to show copiedness / inheritance, or coloured shading to show which branch of an if has been selected.

But for the life of me, I can't see how these new tokens of interaction are going to scale-up. Drag and drop is extremely simple within the space of a screen (or an area a little larger), but will you seriously drag and drop every "if" or "product" when your code is a couple of thousand lines long? Will the lines and arrows be that useful when they point somewhere which takes five minutes to scroll to?

Now, I assume that problem can be reduced if your system permits hyperlinking. In which case, you can click on a parameter to drill back to where it came from. And maybe have a split window or permanent pallet of ur-routines like "identity" which are always in easy dragging distance.

But I still think you're going to hit a moment when it's easier to type

function (parameter, parameter)


parameter operator parameter

on the keyboard than go through the manipulations required to copy it from elsewhere. Think how many possible twenty character function names there are, and every one is within reach of just twenty keystrokes. No graphic manipulation method allows you to navigate such an enormous space of possibilities so succinctly.

Equally, text is highly transportable and manipulable both on and off the computer. I can scribble notes or example code to myself on a scrap of paper. I can read it in a book; or copy and paste it into an email. Or put it on an overhead projector. I can talk about it aload in a pair-programming situation.

It's the same problem as DynamicIdeography. The new tokens are meant to be more interactive and powerful, but the cost is that they are less flexible and easy to construct and manipulate.

Another response : *

See also :