5 ms·

All these live demo applications (like http://livecoding.io/ http://livecoding.io/) are interesting and may be useful for teaching the basics of a language, but

All these live demo applications (like http://livecoding.io/ http://livecoding.io/) are interesting and may be useful for teaching the basics of a language, but I don't see them being used at anything bigger than small demos. A real innovation would be finding a practical use for this type of technology (or a spin of it) in large-scale projects.

seanmcdirmid 13y ago
I basically agree, but live programming is not live coding. Live coding is about programming while the program is actively running (we can argue if performance is involved in live coding or not). Live programming, on the other hand, is about creating a live feedback loop between the programmer and artifact being programmed with the aim of making development easier. Scalability will take some time to achieve, but I think we will get there with some hard work.
- adamwk 13y ago
  Isn't this already achieved with a REPL? I mean other than GUI programming, which something like this would be useful in the same spirit as a REPL.
  - seanmcdirmid 13y ago
    A REPL provides no code editing experience, you can at best just add code progressively one line at time and advance (never rewind) execution.
    - markus2012 13y ago
      I edit and re-edit code in my vim Clojure REPL all the time.
      - seanmcdirmid 13y ago
        Sure, ed supports editing also. The question is what kind of execution feedback are you getting? And for REPLs it's line by line.
        yaxu 13y ago
        That's not true for REPLs which allow interaction with running processes, which is probably most of them.
        seanmcdirmid 13y ago
        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.
        yaxu 13y ago
        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.
        seanmcdirmid 13y ago
    - fsck--off 13y ago
      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-d/3100186-Interlisp_Oct83.pdf http://www.softwarepreservation.org/projects/LISP/interlisp-...
      - seanmcdirmid 13y ago
        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.
- yaxu 13y ago
  In practice the two feedback loops are generally complementary, and I don't see a real need to nitpick or claim ownership of general terms.
  - seanmcdirmid 13y ago
    Right. They are completely orthogonal, and you can have one without the other. This isn't about nitpicking, this is about asserting a clear definition and bring some clarity to this new area, which is just going to flounder if we keep calling orthogonal topics as the same.
    - yaxu 13y ago
      I think you're complaining about someone calling a live programming environment livecoding.io. I think that's nitpicking. The feedback loops are not orthogonal, because programming a running process is rather difficult if not impossible without that programmer feedback loop. The program feedback loop exists within the process feedback loop. A change in programming feedback is highly likely to profoundly affect the wider feedback loop with the running process, and perhaps vice-versa. In this case livecoding.io only seems to be for coding fixed media. Is the program actively running or not? In terms of UX it doesn't really matter either way, so our live coding/live programming distinction is pretty much irrelevant. If it was possible to do animation in livecoding.io then it would be a clearer case of live coding by our definition, but obviously that wouldn't stop it from also being a live programming environment.
      - seanmcdirmid 13y ago
        The program feedback loop doesn't need to exist in the process feedback loop...often they don't, and even in live programming the program is not running in the production real time sense. >In this case livecoding.io only seems to be for coding fixed media. Is the program actively running or not? In terms of UX it doesn't really matter either way, so our live coding/live programming distinction is pretty much irrelevant. Agreed. Such simple systems (like khan academy) tend to be single trick ponies around live refresh. One mechanism doesn't make a story, and so it doesn't even make sense to put it in a story bucket. >If it was possible to do animation in livecoding.io then it would be a clearer case of live coding by our definition, but obviously that wouldn't stop it from also being a live programming environment. Agreed, they can overlap, but how animation was dealt with could lead down either path to the exclusion of the other (does it support improvisation or development). From me on LtU: > In that sense, I'm not working on a new way of programming, just speeding up the feedback loop of our current programming practice. If some new way of cybernetic programming eventually emerges from the faster feedback (unexpected benefits of improved tooling happen all the time), maybe live coding will make more sense to me. Maybe that is the key difference of our approaches. Mechanism is perhaps less relevant than the experience trying to be achieved. In this essay, I described a live programming "make development better" experience. Someone could probably take my videos and describe them with a very different improvised live coding story on top of them also, focusing on activities I don't understand and definitely did not design for, but since the mechanisms involved overlap... This is why terms are so powerful: the use of "live coding", if it stands for something, is a brand that allows us to quickly decide what we are going to see and experience when we click on the link. It will also elicit strong denial from those who don't want to be in that brand, since their problem spaces and approaches are very different.
eddyparkinson 13y ago
live programming of sorts - JavaScript v Spreadsheet - benefits of coding user interactions with a spreadsheet. http://www.youtube.com/watch?v=GuxWduDNgVM http://www.youtube.com/watch?v=GuxWduDNgVM because more people are good with a spreadsheet, than programming. Thoughts?

seanmcdirmid 13y ago

I basically agree, but live programming is not live coding. Live coding is about programming while the program is actively running (we can argue if performance is involved in live coding or not). Live programming, on the other hand, is about creating a live feedback loop between the programmer and artifact being programmed with the aim of making development easier. Scalability will take some time to achieve, but I think we will get there with some hard work.

adamwk 13y ago
Isn't this already achieved with a REPL? I mean other than GUI programming, which something like this would be useful in the same spirit as a REPL.
- seanmcdirmid 13y ago
  A REPL provides no code editing experience, you can at best just add code progressively one line at time and advance (never rewind) execution.
  - markus2012 13y ago
    I edit and re-edit code in my vim Clojure REPL all the time.
    - seanmcdirmid 13y ago
      Sure, ed supports editing also. The question is what kind of execution feedback are you getting? And for REPLs it's line by line.
      - yaxu 13y ago
        That's not true for REPLs which allow interaction with running processes, which is probably most of them.
        seanmcdirmid 13y ago
        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.
        yaxu 13y ago
        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.
        seanmcdirmid 13y ago
  - fsck--off 13y ago
    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-d/3100186-Interlisp_Oct83.pdf http://www.softwarepreservation.org/projects/LISP/interlisp-...
    - seanmcdirmid 13y ago
      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.
yaxu 13y ago
In practice the two feedback loops are generally complementary, and I don't see a real need to nitpick or claim ownership of general terms.
- seanmcdirmid 13y ago
  Right. They are completely orthogonal, and you can have one without the other. This isn't about nitpicking, this is about asserting a clear definition and bring some clarity to this new area, which is just going to flounder if we keep calling orthogonal topics as the same.
  - yaxu 13y ago
    I think you're complaining about someone calling a live programming environment livecoding.io. I think that's nitpicking. The feedback loops are not orthogonal, because programming a running process is rather difficult if not impossible without that programmer feedback loop. The program feedback loop exists within the process feedback loop. A change in programming feedback is highly likely to profoundly affect the wider feedback loop with the running process, and perhaps vice-versa. In this case livecoding.io only seems to be for coding fixed media. Is the program actively running or not? In terms of UX it doesn't really matter either way, so our live coding/live programming distinction is pretty much irrelevant. If it was possible to do animation in livecoding.io then it would be a clearer case of live coding by our definition, but obviously that wouldn't stop it from also being a live programming environment.
    - seanmcdirmid 13y ago
      The program feedback loop doesn't need to exist in the process feedback loop...often they don't, and even in live programming the program is not running in the production real time sense. >In this case livecoding.io only seems to be for coding fixed media. Is the program actively running or not? In terms of UX it doesn't really matter either way, so our live coding/live programming distinction is pretty much irrelevant. Agreed. Such simple systems (like khan academy) tend to be single trick ponies around live refresh. One mechanism doesn't make a story, and so it doesn't even make sense to put it in a story bucket. >If it was possible to do animation in livecoding.io then it would be a clearer case of live coding by our definition, but obviously that wouldn't stop it from also being a live programming environment. Agreed, they can overlap, but how animation was dealt with could lead down either path to the exclusion of the other (does it support improvisation or development). From me on LtU: > In that sense, I'm not working on a new way of programming, just speeding up the feedback loop of our current programming practice. If some new way of cybernetic programming eventually emerges from the faster feedback (unexpected benefits of improved tooling happen all the time), maybe live coding will make more sense to me. Maybe that is the key difference of our approaches. Mechanism is perhaps less relevant than the experience trying to be achieved. In this essay, I described a live programming "make development better" experience. Someone could probably take my videos and describe them with a very different improvised live coding story on top of them also, focusing on activities I don't understand and definitely did not design for, but since the mechanisms involved overlap... This is why terms are so powerful: the use of "live coding", if it stands for something, is a brand that allows us to quickly decide what we are going to see and experience when we click on the link. It will also elicit strong denial from those who don't want to be in that brand, since their problem spaces and approaches are very different.

eddyparkinson 13y ago

live programming of sorts - JavaScript v Spreadsheet - benefits of coding user interactions with a spreadsheet. http://www.youtube.com/watch?v=GuxWduDNgVM http://www.youtube.com/watch?v=GuxWduDNgVM because more people are good with a spreadsheet, than programming. Thoughts?