[seanmcdirmid]

I mostly agree with you, but I think their will be some confusion until we work this out. I'm not sure what Bret Victors refers to his work, but I found the similarities between his work and Chris's thesis to be very striking even though I'm sure they are independent. Perhaps we can harmonize or at least figure out what the key messages are to avoid confusion.

I think you want to provide feedback for each discrete or continuous action by the user. This is quite easy if we are relying on structured editing, but much harder for free form text. My current policy is to re-execute memoization units after each keystroke, though certain syntax and type errors can prevent the executed expression tree from changing (but then the feedback is a syntax/type error!). Getting live feedback also requires toleration to transient syntax/semantic/and execution errors, and to be fairly efficient. In this case, we should tolerate and react to '1' and '10', even if they lead to a program in a weird state (e.g., x - N, where N should be > 100), but you still want to show some kind of change. And this is where live programming is very different: the steady frame that we are viewing while editing should always CHANGE when we edit, meaning it should be focused on some execution result of the code being editing. Doing something without immediate feedback is being a sad panda.

[yaxu]

Yes great, lets try to work this out - you should have an overlong email in your inbox from me as a starter :)

I think I disagree with your definition of "edit". Perhaps this comes down to "chunking" in human perception and action. When I type 100, I don't consciously instruct my fingers to type each character, what I enact and perceive is the number "100". From this perspective, it seems natural for the programmer to control what an edit is.

I've heard VI users talk about edits in terms of breathing. You hit 'w' (or whatever it is they do), type in your edit, then hit escape when you're done. They describe this as natural in terms of breathing rhythm.

Of course in a performance context there is a more concrete requirement that edits need to be timed to happen in a certain way, and everything that happens it part of the output, so you want complete control over what gets interpreted when.. The temporal relationship between programming and output is different from the debugging case which you are more interested in. Both cases are concerned with liveness, but the constraints are different.

[seanmcdirmid]

I program with an IBM Model M keyboard so I can here every keystroke. If you type fast enough, the programmer won't notice intermediate feedback going through 1 10 100. You could even put in a delay but I would hope its not necessary.

As for liveness, I think we disagree on what should be live. I only really care about the feedback loop between the executing program and the programmer editing that program. I don't expect anything else to be live, and actually, it might not even be useful in some cases (e.g., if the program is executing in real-time and is interactive or animated, I have nothing steady to shoot at).

[yaxu]

Nice point about your keyboard, but I'd still contend that a series of fast keystrokes is perceived as a thrum, not necessarily a series of clicks.

If you're programming DSP, then the haptic upper limits of typing is much slower than the limits of aural perception. But I understand more about what you mean by "steady frame" now.

Yes I think you're right in our point of disagreement. In Chris Nash's terms, you're interested in liveness solely in terms of manipulation-driven feedback loop, and I'm interested in it predominantly in terms of performance-driven feedback loop, and only secondarily in manipulation-driven feedback.

The diagrams at the end of this paper might clarify: http://www.eecs.umich.edu/nime2012/Proceedings/papers/217_Fi...

(I've seen a more detailed version of this somewhere, maybe his PhD thesis)