Programming by Rehearsal

[vme131!lsi1!jecel@uunet.UU.NET (Jecel Mattos Assumpcao Jr)]

The problems with "demonstration programming" pointed out by Randy Smith are
very hard to solve. Kuba proposed the spreadsheet as a model, but I haven't
seen a spreadsheet that has a good solution for determining which references
are relative and which are absolute. I haven't used a lot of different
spreadsheets, but the ones I did assumed that all references were relative
and made you edit formula to indicate the ones that were fixed.

About "time browsing" demonstrated code - I don't believe there is a way to
do that as easily as scanning up and down a page of textual code. If the
method is very short this shouldn't be too much of a problem. The question
is: what is the size of most of the methods in the system? I'll bet that if
they are written in a "programming by rehearsal" environment they will tend
to be shorter than if they are entered in a text editor.

"Time browsing" a method could be implemented to look like a UNDO/REDO
mechanism to the user. This would bring programming and using the system
closer together. Of course, a system level UNDO is VERY hard to develop
but it is very important in an Artificial Reality where you work directly
on live objects instead of loading/saving files in tools. One little error
and you might permanently damage a valuable object. That is true of the
Real World too, but we want to avoid the unpleasant aspects in AR if possible.
Anyway, when creating code by demonstration you could go back in time with
UNDO and forward with REDO - just as you would in any part of the system.

Blocks - they break the linear flow of the text and can't be easily captured
as a sequence in time. Parentheses have exactly the same problem. How do you
act out "(a: b) c: (d e: f)" as a series of steps in time? That is what made
the old algebric mode calculators so hard to use - the display showed one
number ( one point in the time sequence ) and the "(" and ")" keys created
invisible states that you had to keep track of in your mind. The Reverse Polish
Notation was a good solution, but it was intimidating for beginners. Now that
alphanumeric calculators let you see the whole expression you are entering at
one time I find parentheses keys usable. So in calculators we've come from
"using by demonstration" to "using by text editing". If the solution to the
parentheses problem can be found ( without RPN ) then the solution for blocks
might be very similar or the same.

Use/mention ambiguity - should user actions be interpreted as demonstrating
code or as browsing the system to get to where the real action begins? Modes
offer one solution to the problem: when the eye icon is open then the system
is "watching" and when it's closed you can browse all you want. Another solution
is to be able to switch between several "open scripts". All your actions will
go into the current method, but you can quickly jump to another method and
come back later to where you were. A global method ( called "history" for Unix
lovers or "changes" for Smalltalk fans ) would aways be available as a scratchpad
or as a command line interface.

Jecel