I spent last week at the remarkable Schloss-Dagstuhl in a seminar on "Collaboration and Learning through Live Coding," organized by Alan Blackwell, Julian Rohrhuber, and Alex McLean (and James Noble, who wasn’t able to join us). It was a terrific event that has me thinking about a whole new set of research questions.
Live coding is a performance where programmers improvise music (and sometimes visuals) in front of an audience. It’s real-time coding to create real-time music. Often, this occurs in pairs, trios, or even larger groups (see a quartet here). One programmer starts his music going, then the other one writes some code to respond and interact, and they both go off. It’s a jam session on laptops.
The main live coding website is toplap.org. There’s another website devoted to AlgoRave — dance parties, driven by live coders generating the music. I still find that a little strange to think about: People dancing to some hacker’s algorithms. For an introduction to live coding, I recommend this video from Andrew Brown, who wrote the JMusic library for music composition in Java that we use in our Media Computation curriculum, and also this video from Sam Aaron on live coding in Overtone. Sam Aaron also created Sonic Pi which is a synthesizer programming environment for the Raspberry Pi.
Most of the attendees (see participant list) were live coders, but there were a number of us others who helped explore the boundary disciplines for live coding. The seminar explored the ramifications and research potential of this activity.
Robert Biddle was there to lead discussions about the software engineering implications of live coding. On the one hand, live coding feels like the antithesis of software engineering, or as one attendee put it, "an ironic response to software engineering." There’s no test-driven development, no commenting, no development of abstractions (at least, not while live coding), no exploration of user needs. On the other hand, live coding (not necessarily with music) can be an important part of exploring a space. One could imagine using live coding practices as part of a conversation with a user about needs and how the programmer understands those needs.
Geoff Cox led a conversation about the humanities research directions in live coding. Geoff has a particular interest in labor, and he pointed out how live coding surfaces hidden aspects of the labor in modern society. While computing technology has become ubiquitous in the developed world, few people in our society have ever seen source code or a programmer. What does it mean for an audience to see an embodiment of a programmer, to see the labor of generating code? What’s more, the audience is seeing code doing something that isn’t normally associated with people’s notions of what code is for — making music. How does this change the audience’s relation to the computing technology? The notion of programming-as-performance is an interesting and novel way of thinking about computing practice, and in sharp contrast to stereotypical perspectives of programming.
Thomas Green, Alan Blackwell, and others from the PPIG (Psychology of Programming Interest Group) community pointed to the notations that the live coders used. I’ve drawn on Thomas’s work on the cognitive dimensions of programming and the implications of our programming representations since I was a graduate student. The language constraints for live coding are amazing. Live coders tend not to use traditional development languages like C++ or Java, but instead work in Scheme, Haskell, and a variety of domain-specific languages (like SuperCollider) — often building their own implementations. Live coders need languages that are expressive, provide for the ability to use techniques like temporal recursion, are concise, and (as one live coder put it) "let me live code at 2 am at a dance club after a couple of beers."
I was there to connect live coding to computing education. I learned the connections from the seminar — I hadn’t really seen them before I got there. I am fascinated by the humanities questions about introducing source code and programmers to a technologically-sophisticated audience that probably never saw the development of code. I’m also interested in the value of rapid feedback (through music) in the performance. Does that help students understand the relationship between the code and the execution? How does the collaboration in live coding (e.g., writing music based on other live coders’ music) change the perception of the asocial nature of programming?
Live coding is rich with interesting research issues because it’s exploring such a different space than much of what we do in computer science. It’s about expression, not engineering. It’s about liveness, not planfulness. It’s about immediate creation of an experience, not later production of an artifact. That makes it worth exploring.
(P.S. I am working a series of blog posts on live coding starting next week at http://computinged.wordpress.com.)
Join the Discussion (0)
Become a Member or Sign In to Post a Comment