| HN Mirror

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.

Hi Sean, yes there may well be different intentions at play, the but also huge overlaps on the technical level. We are all concerned with liveness, and your debugging is my (and I think Bret Victors) exploratory programming.

I can understand your frustrations, lets talk by email about establishing a clearer distinction between performance and more general contexts, if you don't mind. But I think not on the basis that they are completely unrelated, to me it makes sense to think of live coding in social situations (including lectures, dojos,conference talks as well as a/v performances and group music making) is an application for live programming languages.

I can agree reinterpretation per key press is useful in some very particular circumstances, but not others. The difference is not in delay, but in what constitutes an edit.

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.

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.

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

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)

One more point from my phone on the train.. I've also been frustrated with people assuming "live" in live coding refers to a live audience. I prefer to think of it as live electricity. But it is just a really easy way to explain live coding to non programmers.. For whom seeing the results of what you are doing, while you are doing it, is the natural way of things.

I think we both get annoyed in the same way for different reasons :) But your community is high profile because of performances so that's what people tend to see. It doesn't help that you guys are also focused on music and media generation, applications areas that are disconnected from what programmers typically work on.

Heh, well I'm happy to help with this situation, wikipedia might be a good place to start.

Are there good examples of live programming literature that doesn't primarily use media generation in its examples? That might be part of the problem - programming with media is an obvious use case for live programming languages, so people assume the low hanging fruit is all there is?

User interfaces are the classic examples, but I'm going to bring this to compilers in my next paper. It turns out you can easily generate a programmer-observable output for most programs by putting a lot of print statements in your code (barring some device drivers).