[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)