Lambda the Ultimate

Yeah well. I told you, I use vim. ;-P Never got around to appreciating IDEs, really.

But I like your research. It's just that I don't know much about the subject.

Orthogonal. A live programming system could be built with a VIM or Emacs interface. It is just that no one chooses to do that.

I am not sure a live programming VIM would make sense. Vim is good because you can work from a terminal window, alternating between running the program with stdout directly in the terminal, and editing files of any (text) type.

You can already have scripting environments when as soon as the file is saved the new version is detected and used. Does that count as live-programming? After all you don't want to try and run code mid-edit when it might invalid or just plain wrong?

Reload on save isn't really live programming, no state is saved.

APX (what I'm working on now) repairs execution after each edit but will hold off on rollbacks if there is a syntax/type error (but only for the block the error is in).

How is that possible when edits may leave invalid code? If you put each function in a separate file, then it would seem equivalent, because you would save (quit VIM) to commit the changes to a function.

Error tolerant parsing can do wonderful things. You'd be surprised what can be reasonably executed.

I think it would be helpful to find terms for these different technologies and techniques, but I don't think the live coding/live programming distinction has stuck anywhere.

Live coding of music was initially called live programming among other things, but then live coding won over, I think just because it's easier to say.

Some are trying to make a distinction between "live coding" and "coding live" but I can't see that sticking either.

True. A REPL and a code editor + debugger are obviously very different things, but many can't tell the difference when they are souped up. What you guys are doing is cool...but remember the confusion that arose when Bret Victor's learnable programming essay came out (Bret didn't get what live coding was about, the other side didn't get what Bret's work was addressing, points missed completely!). And if Hancock's thesis wasn't so beautiful, I wouldn't be so protective of the word.

So far, we've been trying to name programming experiences, which just isn't done very often and easy to screw up. Experiences are intangible and subjective; technologies often overlap and "LISP" did that is always a correct but pointless answer. Maybe we should just accept that experiences are hard to name and confusion is inevetible. I'm ready to go back to paradigm and technology names (managed time, HUD IDE, omniscient debugging, type-less code completion), since live programming has been so controversial anyways in the PL community (sometimes because it gets confused with live coding, but mostly because the PL community has a heavy bias against programming as an experience vs. a math).

Math can be quite a pleasant and effective experience. :)

Yes, but there are always people at the other end whose needs must be dealt with (at least until we figure out how to replace them with computers). PL really shouldn't be anti programmer, it should focus on the programmer, everything else is supporting. We should really call our field Programmer Computer Interaction.

Mucking around in Mathematica et. al. is a much different experience than having to do everything with paper and pencil. (The latter is not to be abolished, of course.)

I'm not sure whether a REPL and a code editor/debugger are *necessarily* very different. A readline session is essentially a one-line emacs. ipython notebooks live in this grey area by creating an interaction that can be edited into a program of sorts. I made an editor that visualises (what looks like) live state, where every edit the whole program gets evaluated.. So is a read-eval-loop. Personally I find this grey area particularly interesting.

I really think your territorial protectiveness is misplaced. Hancock's thesis is about live interaction with the world through programming, particularly in creative and expressive domains, including music.

I share your interest in experience though, and frustration with any over-protective reaction against it.

The point is that the expectations of the two experiences (programming in the moment vs. programming with augmented feedback) can be quite different, creating confusion and causing work to be judged by inappropriate criteria. It hurts both sides; e.g. if an improvised programming experience is judged poorly because the judges, based on naming alone, were expecting something with time travel. In an ideal world, it doesn't matter, because people will take the time to evaluate your work for what it is.

But everyone is content to just use the terms either way, and let context and related work citations sort out any confusion. This isn't that great for either of us, though, since our citation clouds remain quite non-cohesive and prevents our topics from developing very clear centers. I would like to build a center for my topic around Hancock's thesis, since I think it is great for what it is, but a live coding researcher might not find it very interesting, they wouldn't think of citing it, it is not part of the center for their work! Or put it this way: if live coding eventually comes to be taken to mean what is presented in the "Come Alive" work, how will your own work fit into that?

Anyways, our argument is more about the best way for our topics to coexist in a research world that unwelcomes both rather than if either topic is valid or not. Both should thrive since they are quite interesting and ground breaking topics. We should either be able to name topics with short descriptions that make them clear very quickly, or merge them into a single topic in a cohesive way that makes sense.

That sounds very much about territory.

Having read Hancock's thesis I think it's unlikely that a live coding researcher wouldn't find it interesting. Education, embodied approaches to programming and creativity are of course all core to the emerging live coding field.

You can give me assurances that Hancock's thesis (or Bret Victor's work) is related, but until I read a live coding paper that actually says why it is (puts the work into context), I have nothing to go by beyond that.

In fact, your community is extremely transparent and comes complete with an about statement and a manifesto. If I go by that...well read for yourself, the about statement:

Live coding is a new direction in electronic music and video, and is getting somewhere interesting. Live coders expose and rewire the innards of software while it generates improvised music and/or visuals. All code manipulation is projected for your pleasure. Live coding works across musical genres, and has been seen in concert halls, late night jazz bars, as well as algoraves. There is also a strong movement of video-based live coders, writing code to make visuals, and many environments can do both sound and video, creating synaesthetic experiences.

Here is what the manifesto currently says:

We demand:

• Give us access to the performer's mind, to the whole human instrument.
• Obscurantism is dangerous. Show us your screens.
• Programs are instruments that can change themselves
• The program is to be transcended - Artificial language is the way.
• Code should be seen as well as heard, underlying algorithms viewed as well as their visual outcome.
• Live coding is not about tools. Algorithms are thoughts. Chainsaws are tools. That's why algorithms are sometimes harder to notice than chainsaws.

We recognise continuums of interaction and profundity, but prefer:

• Insight into algorithms
• The skillful extemporisation of algorithm as an expressive/impressive display of mental dexterity
• No backup (minidisc, DVD, safety net computer)

We acknowledge that:

• It is not necessary for a lay audience to understand the code to appreciate it, much as it is not necessary to know how to play guitar in order to appreciate watching a guitar performance.
• Live coding may be accompanied by an impressive display of manual dexterity and the glorification of the typing interface.
• Performance involves continuums of interaction, covering perhaps the scope of controls with respect to the parameter space of the artwork, or gestural content, particularly directness of expressive detail. Whilst the traditional haptic rate timing deviations of expressivity in instrumental music are not approximated in code, why repeat the past? No doubt the writing of code and expression of thought will develop its own nuances and customs.

This sounds like an interesting topic, but it also sounds very very different from what C. Hancock and B. Victor are talking about. Maybe these are outdated, but if so, what is the new story?

For the confusion between to the two topics, the comments here about Bret Victor's work sum it up quite nicely. In it you say:

In fact very few live coding systems exhibit automatic interpretation.

Yes, many of the systems are more like REPLs where changes are compounded; this totally makes sense for an social improvised programming experience vs. a lone programmer writing and debugging their code.

I think what Bret is arguing for in his “immediate connection” principle is bricolage programming, as coined by Turkle and Papert in the early 90s, and a principle driving much of the work in live coding.

Bret, Hancock, and live coding work all spin out from Papert (Hancock's language is in fact called Flogo). They are like three different paths going from the same source in three different directions.

Live coding is about bringing code into live interaction, not some technical implementation of interactive programming. Therefore all he writes about is in fact about live coding.

This is a very strange leap to make. Especially when taken in the context of your next paragraph:

What limits Bret’s argument is the focus on lone programmers interacting with their code. Live coding in general is much more about liveness in terms of social interactions. It’s this social context of live coding, much more than just visualisation, that has been proven to be so beneficial to computing education:
http://dl.acm.org/citation.cfm?id=1047482

The lone programmer with a live feedback experience (what Hancock also focuses on) vs. the live social experience where you place live coding. They are both interesting, and they overlap some, but at the end of the day, incommensurability abounds.

If there is a relationship, then there is a lot of work to do in making it much clearer.

Now please don't get me wrong, I find the live coding work interesting and it is an area that I dream of someday doing something in. But right now I'm working in an area that is very different.

Have you seen any of Victor's articles since he wrote that one? They're increasingly expansive, not about just lone programmers interacting with their code. Have a look at the "humane representation of thought". Of course, the more I've read of Victor's work, the more understanding (and deep respect) I've gained, any concerns I had back then about the lack of context have been very well answered, e.g. by the Future of Programming.

I think the territorial boundaries you're trying to lay down, using other people's work, are incoherent and unproductive.

In Hancock's words: "a good theoretical idea, when embodied in a real-time program, is often also a good interface element for realtime interaction."

Where we are successful, the boundaries melt away, and Hancock's second design principle comes into play "Support a version of programming that is engaged with the world".

I don't have to live by your disciplinary constraints.

You have put out a very crystal clear definitive definition and description of live coding that is quite unambiguous as I've listed in my previous post. I really have nothing else to add since I'm agreeing with you about what live coding is...can't argue with the manifesto!

If you want all of these experiences outside the manifesto to be under the live coding umbrella, well, it doesn't hurt my work in the slightest since the definitional drift (away from improvised coding and toward enhanced feedback during lone programming sessions, as in the "Come Alive" work of this post) is actually what I do anyways. As the definition used in discourse drifts further away from the original TOPLAP definition, well, that is your domain and I'll let you guys deal with it.

Anyways let's end this thread and call you the winner, it works for me. I'm also completely willing to call my work "live coding" if it makes you happy. I guess I must if Hancock's work is firmly there, as you state.

Note that I'm completely sincere (this could be taken sarcastically, but it's not). It really doesn't bother me at all, since again, it actually works for me; the encroached territory is yours and not mine. Continued arguing doesn't do either of our topics any good, so I'll budge and we can let things sort themselves out organically.

I'd rather the TOPLAP manifesto wasn't taken too seriously as a definitional document, although of course having called it a manifesto, everybody does! There's a chapter in the forthcoming oxford handbook on algorithmic music tracing its edit history and taking the motivations behind it (and TOPLAP) apart, in quite a critical way..

Certainly Hancock's thesis is a better umbrella than TOPLAP.

Anyway, gesture much appreciated, lets see how these different threads intertwine..

Good, I feel better now. I have enough enemies to deal with who are against programming experiences as a topic in general; there is no need to weaken allied efforts. We all want radical change in PL, even if we are working on different aspects of it.

I look forward to reading more about it; I do follow this work closely. I'm also making a big announcement in a couple of months, so there will be more to talk about then.

Super, will look forward to hearing more about the big announcement!

BTW the live coding of music community are starting to warm up more to programmer-code feedback
https://nime2015.lsu.edu/proceedings/310/0310-paper.pdf

Looks good. We are still far away on the center (e.g. Compare to Hancock's live text work), but that just takes some work and outreach.