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.
"Live coding is about programming while the program is actively running"
"Live programming [Hancock03] promises for much more fluid feedback between the programmer and a program that is executing while it is being edited."
These statements are connected.
Yes software engineering is a different activity from making music. But, if I want to address live coding of music in particular I just add a word or two. I'm often interested in cross-disciplinary discussion though.
We've been around this a couple of times though, and I think can probably predict each other's points by now. :)
As I've come to understand it, live coding is about programming while the program is actively running, changing the program's flow and behavior in real time as part of a cybernetic melding between programmer and program. Live programming is about better feedback between the programmer and program, which also involves execution, but the program is undergoing development by the alone programmer in a dark room somewhere and is not actively being used, program execution is just to collect data to present to the programmer so they can develop the program!
Whereas live coding has been presented as a new experience that transcends programming as we know it, live programming is just a new twist and substantial incremental improvement on the old programming experience, boring and pragmatic. In much the same way, Victor's Learnable Programming provides similar feedback to improve how programming is taught, and not to revolutionize what programming is.
I used to read a lot of Shadowrun in High School; the decking experience was about hacking through heavily secured computer systems by creating and customizing programs in real time. But when I started doing this, programming turned out to be more of a cerebral experience where real-time problem solving is neither necessary nor (yet) very effective. I'm quite OK with improving on that experience.
> We've been around this a couple of times though, and I think can probably predict each other's points by now. :)
Surely. We need to have a formal debate sometime if we ever attend the same conference.
He says in that same note that he was goaded into writing his "learnable programming" essay by people relating his work with live coding. It seems that for him, discussing improving programming tools was a diversion from his long term aims of uncovering a new way of thinking with computers. His disassociation from live coding seems to be a direct criticism of Khan Academy's approach but maybe he has a more general criticism of live coding... In any case, I wouldn't claim him for my cause either.
I wouldn't dare to claim Victor for my cause, and I'm only reflecting on what he said in his learnable programming essay.
> It seems that for him, discussing improving programming tools was a diversion from his long term aims of uncovering a new way of thinking with computers. His disassociation from live coding seems to be a direct criticism of Khan Academy's approach but maybe he has a more general criticism of live coding...
I don't think this is indicated in his essay. i.e.
> Programming is a way of thinking, not a rote skill. Learning about "for" loops is not learning to program, any more than learning about pencils is learning to draw. ... Thus, the goals of a programming system should be: (1) to support and encourage powerful ways of thinking; (2) to enable programmers to see and understand the execution of their programs
He very much is concerned with programming not as a new way of thinking, but as an existing way of thinking. The examples in his essays then go on to elaborate on programming with better tools to understand execution; it is not a re-invention in any sense. We could try to interpret this passage:
> We change programming. We turn it into something that's understandable by people.
I think this means: we make programming into something that's understandable by people. Comprehensible. Is it change, or is it augmentation? His words imply the former, but his actions (features) imply the latter. Finally we get to:
> Likewise, a well-designed system is not simply a bag of features. A good system is designed to encourage particular ways of thinking, with all features carefully and cohesively designed around that purpose. This essay will present many features! The trick is to see through them -- to see the underlying design principles that they represent, and understand how these principles enable the programmer to think.
Yep, it is about design. He is just scratching the surface of a field I refer to as PXD (programmer experience design) :). The essay then goes onto to present design principles useful in helping make programming more understandable, and examples of those principles at work through various demoed features. Some of those features include some form of liveness; but many don't.
Yes his learnable programming is about improving existing programming tools, but he treats that as a diversion, his other stuff seems quite different.
His recent talk calls for a break from established norms and a return to the free thinking of the early days of computer science. His work combining geometry with syntax (which is also an interest of mine) follows on from that early work, it's as though he's treating the last few decades of software engineering as a diversion.
To me it's quite clear that Victor is calling for something more akin to augmenting and extending human thought, maybe your 'cybernetic melding'. He argues that this software will be used in ways which we cannot yet understand -- he thinks it'll be future generations who develop use and understanding for such technology, he's just chipping away at the possibilities.
But maybe your more approach is more optimistic in this regard, in that you're finding ways that could improve programmers' lives now.
I think my approach is optimistic too, in developing technology through use, taking communities of practice as a starting point, not an end goal.
> He argues that this software will be used in ways which we cannot yet understand
I feel the same way.
> But maybe your more approach is more optimistic in this regard, in that you're finding ways that could improve programmers' lives now.
I'm actually pessimistic that we have much time to innovate. I see programming as a viable profession only for at most another 20 years; by then speech dialogue based systems (aka AIs) are advanced enough to take over on what were programming these tasks before.
I don't see a need for pessimism there. If speech is text plus prosody, then I see adding a prosodic channel to the programming interface as augmenting/enriching programming languages, not replacing them. I also don't think speech is 'special' in terms of intelligence (e.g. Deaf people are just as intelligent), so enriching text could just as easily come in a different form of imagery (prosody being a form of mental imagery) such as drawing. And that is the area that Victor is working in.
>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.