A REPL provides no code editing experience, you can at best just add code progressively one line at time and advance (never rewind) execution.

I'm not quite sure what you mean. By "rewind execution" do you mean something similar to Interlisp's "undo" function?

http://www.softwarepreservation.org/projects/LISP/interlisp-...

Sort of. But if my reading of the manual is correct, interlisp only allows for manual undo and replay; YinYang traces dependencies and repairs program executions automatically after every keystroke. Not sure what is limiting the interlisp environment from doing the same thing.

I edit and re-edit code in my vim Clojure REPL all the time.

Sure, ed supports editing also. The question is what kind of execution feedback are you getting? And for REPLs it's line by line.

That's not true for REPLs which allow interaction with running processes, which is probably most of them.

REPLs allow for interaction with programs (running processes), not code. With direct manipulation, you get a very different kind of liveness: sure you can change the program but their is no repeatable record of doing so (unless Smalltalk style images are used). For code, you just get feedback on the line you just entered and executed.

Live programming allows one to change code to change fate; the running program isn't so much changed as remade, and is completely repeatable.

I think you're mixing up different kinds of feedback, then..

In a REPL, execution feedback can be continuous, not only line-by-line as you said earlier.

If we're talking about 'code feedback', in general yes you do just get feedback on the line you entered.

There's complexity here though. I think of any editor where you execute lines or blocks of code at a time as a REPL, mainly because they're often implemented by piping said blocks to a commandline..

I'd include IXI Lang in this category, and it certainly does have code feedback. You might 'execute' one line, which could set a process going which periodically changes another line of code (and therefore its associated running process).

Perhaps at this point IXI Lang stops being a REPL, and starts just being a live programming language, but I'm not sure at what point that happens. Or maybe REPL is just an outdated term, as they do tend to do a lot more than a linear read-eval-print loop.

> There's complexity here though. I think of any editor where you execute lines or blocks of code at a time as a REPL, mainly because they're often implemented by piping said blocks to a commandline..

This is the crux of a REPL: what would you execute a line of code in the editor though? What does it mean to execute a line of code in a method? Or even an entire method? Development via REPL requires a certain program structure and an aversion away from abstraction (at least in code being developed), and even then the programmer must be manually involved in decided what to re-execute, performing dependency tracking in their head. Smalltalk too actually, where "liveness" often comes from manipulating objects directly.

> Perhaps at this point IXI Lang stops being a REPL, and starts just being a live programming language, but I'm not sure at what point that happens. Or maybe REPL is just an outdated term, as they do tend to do a lot more than a linear read-eval-print loop.

Ya, the concept of a REPL is kind of outdated, but its the term people prefer to start from (e.g. LightTable has an Insta-repl) if they are coming from LISP. I've even heard Smalltalk environments described as a REPL before, even though the metaphors that they depend on are completely different (there is an explicit line-based re-eval though...so maybe they are similar?).

Yes and good point about abstraction - I was surprised when Mark Guzdial noted that live coders don't do abstraction, but I think that's generally true during live coded music performance. I'd like to work on making abstraction more accessible to live coders, and moving away from REPLs should help.

I think we abstract (generalize) much slower than we can usually react with functionality. In machine learning, we actually find that abstracting IS comparable to learning,

Perhaps practicing is a form of abstraction; you practice something now to perform it later...the prepared parts of an otherwise improvised performance?

Yes I agree with your implication that improvised performance requires preparation, and interesting to think of this as abstraction. I think of it as developing a personal 'style', which I suppose is abstract.

I do like to prepare for a performance by making a new abstraction (i.e. a new combinator) but then learn how to use it during a performance. So yes, I make new abstractions in preparation offline, but I'm still working out what that abstraction 'means' online.

I think listening to music is more akin to abstraction in machine learning, as Whitehead puts it, "Art is the imposing of a pattern on experience, and our aesthetic enjoyment is recognition of the pattern." [1]

When I'm performing I think I'm listening to my own music in this machine learning sense, recognising musical abstractions which might not be explicit in the code which generates it.

Also if it's group improvisation there's learning from each other..

[1] I use this quote out a lot, but ironically it's taken from a passage that is protesting against soundbites.