Context : LanguageOrientedProgramming
- JonUdell gets feedback : http://weblog.infoworld.com/udell/2005/01/20.html#a1155
Quick summary / notes
- there is no difference between edit and run time
- you are always manipulaing a fixed document
- however, the document is not a string but a tree-shaped structure
- the main activity of programming is copying and pasting
- however, copies are dynamically linked to what they're copied from (shades of TransClusion)
- this means they inherit from the thing they were copied from, and are updated if the original is updated
- (bit like some of the ideas I was thinking about for BEACH)
- but these are also more like functions
- a function is basically a structure with a number of slots : first argument, second ... until return value
- the slots don't have names but labels (which don't need to be unique, so presumably order disambiguates)
- calling functions occurs through the same copying process. (try to understand this a bit better). Maybe this is like calling as rewrite rules. (ProgramTransformation)
- calling by copying external data into argument slots?
- makes very like a FunctionalProgramming language
- as with all copies, every parameter remains tied to the place its copied from, you can see these ties in the visual editor
- hence the program is a graph of "copied" dependencies
- but has SyntacticSugar to make appear more like normal nested expressions.
- because it's a hierarchical, structured document it's editor is an OutLiner. You can collapse and expand sub-structures (which really are just commented lists)
- plus it has these dynamic / hyper-links between
- Again, it's very like a cross between a SpreadSheet and an XML document. (I bet it is XML behind the scenes, maybe even with XLink?) It has the same dynamic dependencies between cells (slots) but squashed into a different structure : tree not grid.
- reminds me a bit of SmallTalk. It's that different.
- but it looks a bloody fiddle to program :-( How does it scale up to more complex programs?
- concrete vs. abstract. OTOH I welcome thinking about concretes not abstracts. OTO manually dragging and dropping four line if structures every time you need if, especially once the program gets to be hundreds of lines long, looks laborious.
- In fact, I suspect Edwards is wrong focus on, and wage war against text as the medium for programs. Compare my discussion of DynamicIdeography. If you do away with text descriptions (which you do in visual programming, with certain IDEs, with IntentionalProgramming or SubText) then you actually dispense with a highly flexible, powerful and descriptive tool : assembling characters from a short alphabet, and need to replace it with something less familiar, flexible and expressive. For example, dragging and dropping works fine over very short distances, but I can't see how it can scale to large programs.
(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.
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 : * http://bannister.us/weblog/?p=192