Be sure to read the comments – Sam Aaron makes some important corrective points… The below left as documentation of thinking-in-progress.
There is now an exciting resurgence of interest in live programming languages within certain parts of the software engineering and programming language theory community. In general the concerns of liveness from “programming experience design” and psychology of programming perspectives, and the decade-old view of live coding and live programming languages from arts research/practice perspective are identical, with some researchers working across all these contexts. However I think there is one clear difference which is emerging. This is the assumption of code being live in terms of transience — code which exists only to serve the purposes of a particular moment in time. This goes directly against an underlying assumption of software engineering in general, that we are building code, towards an ideal end-game, which will be re-used many times by other programmers and end-users.
I tried injecting a simple spot of satire into my previous post, by deleting the code at the end of all the video examples. I’m very curious about how people thought about that, although I don’t currently have the methods at my fingertips to find out. Introspections very welcome, though. Does it seem strange to write live code one moment, and delete it the next? Is there a sense of loss, or does it feel natural that the code fades with the short-term memory of its output?
For me transient code is important, it switches focus from end-products and authorship, to activity. Programming becomes a way to experience and interact the world right now, by using language which expands experience into the semiotic in strange ways, but stays grounded in live perception of music, video, and (in the case of algorave) bodily movement in social environments. It would be a fine thing to relate this beyond performance arts — creative manipulation of code during business meetings and in school classrooms is already commonplace, through live programming environments such as spreadsheets and Scratch. I think we do need to understand more about this kind of activity, and support its development into new areas of life. We’re constantly using (and being used by) software, why not open it up more, so we can modify it through use?
Sam Aaron recently shared a great talk he gave about his reflections on live programming to FP days, including on the ephemeral nature of code. It’s a great talk, excellently communicated, but from the video I got the occasional impression that was is dragging the crowd somewhere they might not want to go. I don’t doubt that programming code for the fleeting moment could enrich many people’s lives, perhaps it would worthwhile to also give consideration to “non-programmers” or end-user programmers (who I earlier glibly called real programmers) to change the world through live coding. [This is not meant to be advice to Sam, who no doubt has thought about this in depth, and actively engages all sorts of young people in programming through his work]
In any case, my wish isn’t to define two separate strands of research — as I say, they are interwoven, and I certainly enjoy engineering non-transient code as well. But, I think the focus on transience and the ephemeral nature of code naturally requires such perspectives as philosophy, phenomenology and a general approach grounded in culture and practice. To embrace wider notions of liveness and code then, we need to create an interdisciplinary field that works across any boundaries between the humanities and sciences.
“Is it possible that software is not like anything else, that it is meant to be discarded: that the whole point is to always see it as a soap bubble?” – Alan Perlis
When I was discussing Ephemeral Programming in my FP days talk, I wasn’t discussing it as a technique to replace their traditional software processes, more of a new technique to add to their toolkit which could facilitate a more effective communication feedback loop with software processes. I argued that this could be achieved by treating programming languages as interfaces in their own right and grounded it with industry-relevant problems such as the manipulation and querying of so-called ‘Big Data’.
The crowd can’t have been too alienated as in the conference voting process, the talk was rated the best of the entire conference.
Still, I think you are referring to something that exists in that we still have a huge job of teaching people the value of transiency in programming not just to aid prototyping, practicing, pedagogy , arts practices but also for working in new business contexts.
Still can get what do you mean by using the term ‘new business’, but I am quite sure this is related to business. Furthermore, I am quite sure that you are trying to say that the ‘busy style’ is immediately related to Ephemeral Programming.
I saw your talk on EP, and the demo on Overtone. In a musical performance the only thing that matters is that of interpretation (ερμηνεία in greek language, unfortunately there is a gap in translation. In Oxford dictionary type ‘interpret’, and see 1.second bullet and 2), and this has nothing to do with ‘busy-ness’.
The great Greek poet K. Kavafis was trying to show that, by saying for polytropos Odysseus in few words that, ‘only the journey matters’ (see poem:
Ithaca).
We are trying to communicate to each other using both the nowadays lingua franca, the English language. You are a native British speaker and I am a native greek speaker. When you say ‘science’, you refer to ‘pure knowledge’. When I say ‘science’, I refer to ‘επιστήμη’, meaning ‘standing above’. In a sense, ‘επιστήμη’ is related to empirical knowledge, while at the same time this is not excluding theory and logical knowledge.
To conclude, for sure powerful tools and methods, like yours Emacs Live and Overtone, are welcome in the process of evolution and actually these are our drivers into this journey. But we all have to be aware of how we are using them, or communicating them if you would like. Finally, AFAIK business was never immediately related with the foundations of art & science.
I’ll following your lead with this blog post by rambling some thoughts incoherently.
I think that the how willing we are to accept the transience of something we have created often ties in with how much time and effort we invested in creating it, and, also how much time and effort would be involved in recreating something similar.
A program is generally expression of one or more ideas, e.g. sed is an instance of the idea of a simple line editor built around regular expressions. Expressing that idea is easy, but writing a sed implementation would take a long time. There are a bunch of edge cases for example that usually only become apparent once you try and use a tool for real work.
Haskell is an interesting case here: it seems that in the case of Haskell the ideas are a lot more complex than the code itself. Once you understand e.g. functors you realise they are a super simple concept and can be implemented in a few lines of C++ templates or whatever else. So the value of the code of an implementation of a type system supporting functors is quite low, but the actual idea is super complex (at least to me).
Where I’m going with this is that in music it’s very common to improvise. Unless you’re recording the whole time, this is quite a similar activity to writing code and throwing it away once it’s been run. And just like when writing code, even though you jammed for an hour and coudn’t reproduce a single minute of it note for note, a whole bunch of ideas will have been spinning around your head and developing and maybe some of them will stick with you and you’ll turn them into structured tunes and record them, or just use them as a starting point for future work.
My attitude to programming has developed along the same lines (it took a long time to get there). The goal is to develop whatever idea / whatever need is at the heart of what I’m doing as fast as possible. Later on it can be tested, structured, formalised etc. but first I’d rather discover if the approach will actually work at all.
So, I think the act of composing a piece of music out from a basic idea and the act of testing, debugging and making a program user-friendly and reliable are kind of related. And this kind of informs my opinion on free jazz 🙂