Clint Morgan

Problem

Programming is hard. The author attributes the standard text string representation of programs as a major source of this difficulty.

Contributions

The author proposes an alternative medium for representing and constructing programs called Subtext.

In Subtext, the programmer interacts with a semantic model of the program (whereas in traditional text-based languages the interaction is with the syntactic model). The semantic model consists (roughly) of nodes and edges in a dataflow graph. The model is viewed and edited using a GUI and the program executes during the editing process much like a spreadsheet. This could be called WYSIWYG programming.

(I found the demo at [subtextual.org/demo1.html] a better presentation of the Subtext language/system than the description in section 2.)

Weaknesses

The underlying premise that a large part of programming's difficulty comes from their textual representation is not supported.

The thesis "Subtext makes programming easier" is not validated.

Much of the language description/discussion is hard to follow as the author uses many terms and concepts invented for Subtext.

Questions

The main question raised by this paper is: Will such a WYSIWYG programming system ever be competitive with modern text-based languages? An alternative is: Is there a niche activity which Subtext-style programming is ideal?

Do Overt Semantics really "dispel the mystery of debugging"? It seems that even when the semantics of each operation are clear, the large-scale behavior of a program can still be mysterious.

Is language extension through presentation (section 3.1) really novel? Isn't this what all the IDE's do (eg, syntax highlighting, method hiding, refactoring wizards)?

How could this approach scale to programming in the large? The author claims that text-based approaches could be used. (This seems to contradict the distinction with text-based languages the author preaches)

Belief

While Subtext may be a "neat" way to program, I do not believe such approaches provide a viable alternative to modern text based programming languages for general purpose programming. Perhaps there is a niche domain in which such a language is ideal (similar to spreadsheets in accounting).

Brian de Alwis

Problem

Programming and its representations are bound by paper-centric textual conventions. The affordances offered by these text strings are not meaningful in the context of actual program development. We should instead have programming systems that provide manipulating the programs using conceptually meaningful operations.

The author proposes the concepts embedded in Subtext: * Removal of Names: names are not required, used only to communicate meaning * Semantic Editing: editing semantics are those used to create programs * Overt Semantics: the program is always running (no edit/run differentiation); there is no need for a separate run or debugging session, as live values are always shown

Contribution

* describes a new programming language and supporting development environment * provides some new UI techniques for investigating the definition points of variables (the compasses)

Weaknesses

* The author should be required to memorize the definitions of `hyperbole', `diatribe', and `unsupported statements' before being allowed to write another paper.

* The analysis of the difficulties of programming is simplistic: these difficulties of programming (`inhumanely hard'?) are more than simply mismatch of editing semantics. This causes difficulty in valuating the merits of Subtext and the ideas, and the evaluation of Subtext seems flakey. The real difficulties (to me) in programming the ideas are in evaluating the effects of changes, which do not disappear with Subtext given the automatic propagation.

* I think the tirade about names is missing a deeper point. Humans make great use of analogical reasoning. By being able to identify something as an instance-of something else, they can reason about that new thing. The paper does not describe how Subtext solves the problems otherwise solved with delayed binding. Or do they not happen?

* Creation by copying: although values are copied, they are automatically updated on change. But I see no way of examining where a value has been copied to. So if I need to change a function/value, I have to find all matching parts of the tree?

* The paper doesn't convince me that it is fundamentally different from structural editing (syntax-directed editors). It's not clear how Subtext addresses the difficulties experienced by structural editors.

Questions

* What would be a convincing evaluation of the (or any) language? Is it really a negative if developers need substantial training to become effective? Should we have a head-to-head competition to see who can code factorial in the least amount of time?

* The author appears to consider the language to be inseparable from from the environment. Is this true? Is it actually important? If the language can be separated, then some of the supports could be folded into other environments. Given that nodes retain identity, it seems there are implicit names being retained below the covers.

Belief

am I convinced? No. But it looks interesting.

Andrew Eisenberg

Problem

The author argues that programming as it is currently practiced is more complicated than it needs to be. He describes two usability problems: the Gulf of Execution (the problem of understanding what value a program will produce when executed) and the Gulf of Evaluation (the problem of tracing values back to how they were calculated from within the program). Both of these problems are inherent in the use of current text-based languages.

The solution described is a new programming environment where the representation of the program is aligned with its execution. Any change to the program immediately causes re-evaluation of the program and a change of its state. All changes to the program are created by copying and pasting existing nodes into new locations. Copying comes in several forms: linking (the two change as one element), imperfect copying (arguments of a copied unction can change from original, but not internals), varying (change in original reflects to copy, but not vice versa), and snapshot copies (after copy, no relationship between original and copy).

Also, a proof of concept implementation is described.

Contributions

Working implementation

The author raises interesting alternatives to some current programming practices: * All code executes immediately after an edit * Immediate binding---no symbolic names * Programming by example and built-in testing * All edits are semantic transforms * All edits are some kind of copying * The copy relationship between two nodes can itself be copied. This is termed higher-order copying * Presentations, separating presentation from the syntax tree

However, which of these concepts are truly new?

From what I can tell, higher-order copying, and immediate binding (lack of symbolic names) seem to be new concepts introduced in this paper. The others, in some form, are not entirely new.

Weaknesses

- Can this scale to more than 10 lines? There are at least efficiency and usability problems.

- I am not convinced that combining edit/compile time with runtime semantics is good for understanding, efficiency, or usability. For one thing, any reasonably sized program will take order of magnitudes longer to execute than to make a single change to. A programmer cannot wait after every time change for it to propagate through its execution. Partial evaluation can help, but I don't think would solve it.

Questions

? The obvious questions are: does this really work, can this scale, and is this truly simpler than regular programming? Although this paper doesn't answer these questions, to what extent are these questions even answerable?

? Can any pieces of the Subtext environment be extracted and used without adopting the whole technique?

? How general are presentations? Can they be used to created general user interfaces where the user doesn't have to program?

? Can types of copying and higher-order copying be applied to existing languages?

? What are the implications for creating libraries and frameworks using this style of programming?

? What is this thing like to use?

Belief

What initially drew me to this paper was the idea of presentations, or providing a stylesheet over an existing language or AST. There's a lot of power in being able to redefine a program's display. However, this idea wasn't developed as much as I would have hoped.

I don't believe that this style of programming will ever become viable for large systems, but I think there might be some promise in some of the ideas. In particular, I think the work on copying could be valuable.