Alex, I've ready up on as much on live coding as I could, I've even read parts of your thesis. I really like the work, but the intention of the work is completely different.

> Live coding is absolutely everything about live feedback. This gives you access to performing in front of a live audience, but that is only part of it. It also allows new styles of collaborative programming, and exploring of ideas in composition.

This really isn't the point. The "live feedback" is not about performance, its not about new styles of collaborative programming, its not about composition of time-based media. It is simply a better way to debug your program, it is simply better feedback to the programmer while they are writing their program.

> Live coding is about using programming languages to manipulate running code, maintaining state (if there is any).

You've stated this differently before:

> For me, live coding is about live, end-user programming of time-based media. Live coders write software for themselves, and the timeline of software development is often shared with the end result. This brings both social and creative aspects of programming to the fore.

Now, imagine my frustration when I'm trying to promote a new way of debugging a program, and people say "we've heard about this before, but we aren't very interested in music." Do you understand why I'm frustrated? Live programming aims to change programming in general, you should be able to live program a web app, a map reduce program, an operating system, a compiler, anything! This is not the goal of live coding as I understand it.

> Check out the code in the "hacking perl in nightclubs" article that this one links to. The software it discusses takes on live updates without restarts or losing state (in fact, the code in the editor is part of the state).

But you see, that's where our disconnect is: LP is not just about updating code without losing state, its about changing the entire program's state as if the new code HAD ALWAYS existed. Simply preserving state is not good enough. Now in a dataflow language (like quartz composer), there is no state and you simply re-execute the new wiring; very easy. But if there is state involved, the problem becomes much harder. The live coding crowd hasn't done anything to solve that problem yet, and in fact, they don't really need to; it seems like preserving state is sufficient for your use cases.

> It also has an option to take on edits every keypress, but it's off by default, because it's impractical. Sometimes you just don't want 1 and 10 to be interpreted on the way to 100.

Did you ever watch the quicktime videos embedded in my 2007 paper? I did just that ('1', '10', '100') and the effect was quite nice; I got applause right there when I gave the talk at Onward. It is definitely a UX challenge, and Chris's discussion about steady frames, I think, is the key to a decent live programming experience. Also, Bret Victor's demos have no delay in them whatsoever; continuous feedback can be nice and exciting. Of course, we need to do a lot of UX and implementation work before it is actually practical. The live coding community has working systems today, you guys already have what you need; we don't, we just have a bunch of prototypes and demos (unless we count visual languages where liveness is easy).

> Live coding arose in an interdisciplinary context of music performance, pedagogy, media theory, psychology and computer science.

Sounds like a nice focused story to me :)

> The thesis you link to is really excellent, but has shared roots with live coding and is referenced in the live coding literature.

The important point to make about Chris's thesis is that it is very close to Bret Victor's demos and goals as stated in his learneable programming work. That this is a new way to understand code while we are writing code, the story is very narrow, nice, and easy to understand; there is no reason to expand it in other ways.