4 ms·
Ok here's two quotes from you: "Live coding is about programming while the program is actively running" "Live programming [Hancock03] promises for much more f
by yaxu 13y ago
Ok here's two quotes from you:
"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. :)
- seanmcdirmid 13y agoAs 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.
- yaxu 13y agoI think this is an insightful distinction, and as you've said before such incremental work could lead to a major shift. But you can't claim Victor for your cause, he is explicitly concerned with reinventing programming, and not incremental improvement. For example he says his "Up and Down the Ladder of Abstraction" essay is his personal manifesto, and that "it's not about programming. It's about a way of thinking". http://worrydream.com/MediaForThinkingTheUnthinkable/note.html http://worrydream.com/MediaForThinkingTheUnthinkable/note.ht... 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.
- seanmcdirmid 13y agoI 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.