Lambda the Ultimate

to me it means sorta like acceptance tests + quick check + data/alg visualizations all hyper fast in some cool dashboard in a brett victor (foil for all the people before who have said the kinds of things he said) ide so that i can be in the "start with the null program and work your way up and noodle around with things lively and have the bidirectional code/docs/effects/gui/lookandfeel update that really works and doesn't suck" happy place. so things can't ever be allowed to just explode due to my 'bug' and tear everything down, etc.

Hey Sean, could you elaborate a bit? Performers have to deal with problem spaces too.. Do you mean applying live coding to well defined and immutable problems?

I meant writing programs to solve problems, what most programmers do with programming. Live coding seemed to me like improvised use of something used for work as a more artistic instrument (say, turning a barrel into a drum), but you've pointed out in the past that this wasn't the case. So I wonder, with the broad swath of people at dagstuhl, if you guys had discussion about live coding beyond or aside from the performance aspect?

But I'm not reading anything different. From the Guzdial blogs:

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.

...

Live coding is about performance. It’s not an easy task.

I think you've argued with me in the past that this wasn't the case, but I think that "performance" continues to be the impression. So how would you today frame Bret Victor's work, for example, from a live coding perspective?

So you would you say the main function of programming is solving well defined and/or immutable problems?

If that's what you mean, no live coding does not make much sense in that context. We talked about programming as a creative and social activity.

Creative problem solving is of course useful in many lines of work.

I'm totally for ad hoc on the fly problem solving, and I would not mind hearing your story from that perspective. I still have no idea how the performance aspect would be related to dynamic problem solving, so talking about how those activities are related would help a lot.

Hi Sean, it will take me a few days to answer this one I think, I'll give it some thought.

Ok, giving it a go.. Introspecting in this way is difficult, and thinking aloud here leaves me rather exposed, so with some trust..

My live coding performances are generally fully improvised, in the sense that the music has not been written before I start. So you start with the problem that there is no music playing. Then once you've solved that, you then have the problem of how you are going to stop playing (this is nontrivial, assuming you want to induce a sense of resolution).

Then there's all the problems between those two points - what do you play? You have to surf a Wundt curve to keep the music interesting, pushing against the edges of the problem space (e.g. the musical genre/style), without pushing too far into being nonsensical. That is, you have to take into account all the other music which led you up to that point.

When improvising with other people (which is what I tend to do, through various collaborations, with other live coders, dancers, instrumentalists, live artists etc), these problems look rather different. For example starting at the same time as someone else, and quickly negotiating a theme to explore and manipulate, is nontrivial. This is a problem of entrainment on multiple levels, coordinating changes, arranging juxtopositions and accompaniment in time, timbre and harmony space, call-and-response, and so on. These problems are unique to the particular combination of people and the context. Coming to a resolution together in a satisfying manner, is also a problem that takes a great deal of experience and skill to solve.

Then if there is an audience present as well, you have the problem of keeping them engaged, when they are not making music themselves. That is unless you are producing ambient/background music, in which the problem is managing their engagement, or supporting multiple levels of engagement. If on the other hand they are dancing, you have the problem of shaping the music in a way that keeps them dancing, which might involve engineering drops, quoting familiar structures, and producing rhythms which can be better understood through dancing.

Then there is the problem that music is continually reinventing itself, and you have to come up with new problems all the time. To keep things fresh, I like to introduce new structures to my system prior to the gig, so that I have a rich problem space that I am still exploring and learning about during a performance.

On a more fine-grained level, every edit poses a new problem - is the change good, what does it mean, what should the next change be? I could give some detailed examples and analysis here but I think I'll do that in the context of writing a paper :)

If you think the notion of problem solving in the above is irrelevant to software engineering practice, I think you'd be very wrong.

In 1961, Alan Perlis gave a talk at the MIT Sloan School ("Computers and the World of the Future," Martin Greenberger (ed), 1962) where he argued that every undergraduate should take a course in computer science, including programming. He argued that programming provided a new way of thinking. He suggested that you can't think about integral calculus in the same way once you understand iteration. He wanted that way of thinking to be accessible to everyone.

Peter Elias, head of Electrical Engineering at MIT at the time, pushed back. "If the computers, together with sufficiently ingenious languages and programming systems, are capable of doing everything that Professor Perlis describes—and I believe they are (and more)—then they should be ingenious enough to do it without the human symbiote being obliged to perform the mechanical chores which are a huge part of current programming effort, and which are a large part of what must now be taught in the introductory course that he proposes." He didn't want to teach programming.

J.C.R. Licklider (another one of Perlis's discussants) responded. "Peter, I think the first apes who tried to talk with one another decided that learning language was a dreadful bore…But some people write poetry in the language we speak." Perlis also responded. "The purpose of a course in programming is to teach people how to construct and analyze processes…A course in programming is concerned with abstraction: the abstraction of constructing, analyzing, and describing processes…The point is to make the students construct complex processes out of simpler ones….A properly designed programming course will develop these abilities better than any other course."

In keeping with the focus of this forum, it's worthwhile giving John McCarthy's take (who was also in the audience). "Programming is the art of stating procedures. Prior to the development of digital computers, one did not have to state procedures precisely, and no languages were developed for stating procedures precisely...One would suppose that appropriate languages for describing procedures will contain components that have a lot in common with mathematics and which contain a certain amount of mathematics; but they will also contain other things which are yet to be developed."

Here we have some of the people who invented Computer Science (alright -- Licklider invented the Internet, not CS) saying that programming is for communicating process, for describing process, for creating and analyzing processes, as a tool for thinking with, for inventing new ways of describing procedures, and even for developing poetry. It's not just about problem-solving. Performance is a great way to explore languages for communication, for expression, for describing procedures (e.g., in music), and even for poetry. Live coding is about rapid feedback loops, which is useful for the goals of communication and expression. For my education interests, I'm curious about the role of live coding performance for inspiring greater interest in CS and music. If we limit our focus to just what people use programming for now, then we're being short-sighted.

I don't program to describe a procedure, the procedure emerges to decompose a problem I'm trying to solve. The feedback loop is a means, not an end; I don't program to express myself in much the same way that the bricklayer is just laying down bricks and not dancing. I instead express myself through the programs I write, the artifacts that result from laying a lot of bricks.

Live coding seems to change the feedback loop into an end in itself, which is quite alright if not how I think most of us do programming. But from that perspective, I think there needs to be an honest discussion on where that is interesting or useful, lest many of us "just not get it."

Yes I inhabit that feedback loop, exploring ideas within it, rather than thinking as code as external to my thought processes.

Have you read Turkle and Papert's paper on epistemological pluralism, Sean?

http://papert.org/articles/EpistemologicalPluralism.html

I think reading that, and then re-reading the section in Hancock's thesis on "tinkering", might help you to understand an alternative way to think about and do programming.

From Hancock:

"Like the bricolage of Levi-Strauss (1966), programming-by-tinkering is a process guided neither by well-formulated plans nor by firm goals. instead, the tinkerer responds rapidly and flexibly to emerging results of partial constructions, and may arrive at an end product very different from that initially envisioned—if an end product was invisioned at all. Programmers with a solid structural understanding of the programming language may sometimes program by tinkering. However, for the many learners whose structural understanding is not fully developed, tinkering is an approach that helps to leverage satisfying results from incomplete knowledge."

This resonates with Victor's "thinking the unthinkable". Using language and geometry to explore problems that you don't understand.

From Turkle and Papert:

"The development of a new computer culture would require more than technological progress and more than environments where there is permission to work with highly personal approaches. It would require a new and softer construction of the technological, with a new set of intellectual and emotional values more like those we apply to harpsichords than hammers. If computers are really the tools we use to write, to design, to play with ideas and shapes and images, they should not be addressed with the language of desktop calculators. Moving out of the impasse also would require the reconstruction of our cultural assumptions about hard logic as the "law" of thought. Addressing this question brings us full circle to where we began, with the assertion that epistemological pluralism is a necessary condition for a more inclusive computer culture."

A more inclusive computer culture is an important motivation. For me, this isn't just about creating better tools for the software engineering community, but giving a wider and bigger group of end-user programmers better environments to express themselves in.

I'm a big fan of tinkering and software bricolage; programming itself is a problem solving activity that can also help in discovering what the problem is. I also spent a couple of years rapid prototyping for a design studio, so was also in the thick of it with nonprogrammers (even wound up marrying a UXD). But the journey is still quite personal and private, only the destination is shared.

That being said, you don't need special tools to tinker, while end user programming is perhaps helped along by it but is definitely not equivalent (programmers tinker also). Better feedback helps, live feedback helps, but this has nothing to do with an audience, performance, or directly with social aspects that live coding seems to be addressing. Is bricolage a separate topic with technology overlaps, or am I missing a connection between the two topics?

I think you raise a big and interesting question, Sean. Part of the question for me is who is the tinkerer. Programmers who tinker may look different than the broader audience of people who might tinker. I'd like to support a broader audience of tinkerers -- the kind who might do more bricolage-style programming. Programmers in the US still tend to be a homogeneous lot (e.g., mostly male and white or Asian). Betsy DiSalvo's work suggests paths to draw in more African-American CS students (http://computinged.wordpress.com/2010/03/16/the-challenge-of-engaging-african-american-men-in-computing/). Would different technology for tinkering draw in a different population of tinkerers?

We are all tinkerers, it is a normal part of program as well as programming skills development. Especially for researchers, we tinker a lot to increase knowledge and experience, or perhaps just to generate new ideas. But there are still goals, problems that drive everything.

When you have a social problem, why look for a technological solution? I disagree with Turkle's hypothesis that programming tools are biased at all to the way white/Asian males think; European and Chinese are fairly different mind sets yet the tools do just as well for either. The lack of diversity in the field is definitely related to educational and cultural issues.

I agree that lowering the programming barrier universally can only be a good thing, but you wouldn't increase diversity so much as grow the pool. Better tools for tinkering would be welcomed all around.

Yes they can be considered separately, inasmuch as music composition and music improvisation are separate topics.

They can also be considered together. We can tinker together, through multi-user live programming systems like the reactable, the powerbooks unplugged republic and google spreadsheets.

The lone programmer might be the norm now, but that needn't constrain us. I'm with Bret Victor here -- we hardly know what programming is, and it'll be a future generation who will make sense of the next wave of richer programming environments.

[Sorry about this Sean, but live coding isn't *just* about performance, although that is a focus. It's also about solitary exploration, and has been from the start, e.g. Julian Rohrhuber's film scoring.]

I don't really care how live coding is defined as long as I can get at a cohesive definition for my own understanding. If one claims live coding includes performance as well as improvised interactive programming, it begs the question of how these two topics are related. Hopefully, live coding is not just a random (non-cohesive) set of topics that a particular group of people are interested in! Just because A and B can co-exist doesn't make them cohesive; the peanut butter and chocolate must have some sort of synergy. For example, how does a social element especially complement improvisation?

Now for a personal opinion unrelated to narrative quality:

Some people are already playing around with pair programming, but it smells of LCD design by committee to me. I'm very much an individualist as far as design, science, and engineering are concerned; I hope programming isn't redefined as some sort of Borg-like activity.

We will define our own richer interactive programming environments today, but I think it requires moving past LISP and SmallTalk. We can do much better than that.

The connection between live coding composition and live coding improvisation is not random, it's completely obvious: live interaction with code.

Why on earth do you think that a community needs to have such an unreasonably narrow and singular focus?

If you want to talk about something more specific than the collective interests of a multidisciplinary community, then just *use enough words*. If you want to talk about live coding performance, then do so -- it's only one extra word!

When improvising music with code with others, I'm working with live notation. As a music composer I'm doing much the same. It makes perfect sense to talk about these things within the same terms.

This is exasperating, I think I'll just have to stop taking the bait.

You seem to throw out some random phrases, state a tautology or two, and call it an argument even if it's absolutely devoid of any content.

This is exasperating, I think I'll just have to stop taking the bait.

It is quite up to you. I'm happy to politely write around live coding when describing related work because I still, at this point, have no idea what it is or what it is for; it just, as you say, exists.

Random phrases such as what? If you don't understand some terminology I'm happy to explain.

Perhaps we are talking different languages, let me try harder:

The connection between live coding composition and live coding improvisation is not random, it's completely obvious: live interaction with code.

You basically repeated three words here: live, interaction, and improvisation, without any content or insight (because it's obvious that A = A?). How are interaction and improvisation especially related in the live coding sense? I interact with my code daily, obviously, and improvise what to code based on that feedback, but what is special here?

Why on earth do you think that a community needs to have such an unreasonably narrow and singular focus?

Communities should be distinguishable from other communities, branches should be recognizable from the main, they should organize around some common theme, technology, or activity. At the end of the day, it really is just a bunch of people with a similar identity, but if you want influence outside of your circle, you need to come up with a cohesive story, or people just won't latch on to anything.

I assume you guys/gals want influence, and it probably hurts a bit whenever your works are misunderstood.

If you want to talk about something more specific than the collective interests of a multidisciplinary community, then just *use enough words*. If you want to talk about live coding performance, then do so -- it's only one extra word!

I'd prefer to not talk about it at all actually. I just hate when my own work is labelled by someone as live coding, and then they ask when I'm going to start making music!? I just read two blog articles that you posted from Dagstuhl that live coding was about performance, so why would others think otherwise?

Thanks for your efforts Sean, lets get through this!

How are interaction and improvisation especially related in the live coding sense? I interact with my code daily, obviously, and improvise what to code based on that feedback, but what is special here?

By "improvisation" here I mean in the musical sense e.g. from Jazz, and can see why that would be confusing. Improvisation is an established form of performance (often shortened to 'improv') where musicians compose the music while they play it. Composition is where musicians work on a piece of music off-line. Improvisation is usually with an audience, composition is generally not.

Live coding performance operates some way between these two. You're not completely "in" time, as an instrumental performer is, for example you can schedule events which unfold in the future. However you are still bound by time, because you can't change the start of the piece once it has played.

Even though composition generally doesn't have an audience, it might still benefit by the bricolage-style live coding approach, as a creative way of working with code.

By live interaction I'm talking about manipulation feedback (using Chris Nash's terms) -- working with code with continual feedback via its output and/or visualisation of data and process. I distinguish manipulation feedback from performance feedback - where the feedback loop going through actions in the outside world which might include an audience.

Is that any clearer?

Communities should be distinguishable from other communities, branches should be recognizable from the main, they should organize around some common theme, technology, or activity.

I'm happy being a member of an inclusive live coding community. I'm also happy joining a different community that is more focussed.

Live coding is mostly about performance, but it's also about composition, and explores wider cross-disciplinary concerns. I'm happy if you or anyone else say "live coding is about programming in performance", it gets the idea across quickly. But when we are talking about the activities and direction of the whole field, there are important nuances.

I just hate when my own work is labelled by someone as live coding, and then they ask when I'm going to start making music!?

I understand your frustration, and I've tried to help. I've stopped using the phrase "live programming" in musical contexts, and tried to disassociate the terms in a way that makes sense (the activity of live coding vs the technology of live programming languages). This is not easy because "live coding" and "live programming" has been used interchangeably for the past ten years (e.g. http://art.runme.org/1107861145-2780-0/livecoding.pdf), but I'm very happy to help make way for discussion in CS that doesn't come with musical implications, partly because I also have strong research interests in CS.

The truth is, that these are overlapping communities, and your work is of great interest to live coders, even if you hate being associated with music.

From my perspective it's really wonderful to hear that people are associating code with music, and great that venues like the LIVE workshop are bringing people together, and pushing shared concerns forward.

[By the way, I'd imagine if the LIVE participants tried to narrowly define "live programming", then I think similar controversies would turn up. It'd be interesting to hear whether this was attempted..]

It's worth noting though that your frustrations with music aren't universal. While establishing Live Programming as a new research field, the LIVE workshop folks were happy to connect with the various histories that have led us to this point, including getting Thor Magnusson to talk about the history of live coding.

This gets it about right:
http://liveprogramming.github.io/liveblog/2013/01/a-history-of-live-programming/.

I understand that. I'm not sure why manipulation feedback should be considered as a new thing; we obviously had it before, it was just very slow! 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.

I was kind of hoping to hear about some sort of resolution related to our debate coming out of dagstuhl, but felt a bit let down when I read about a lot of performing. Again, it's just not my thing, and much of the humanities perspective is lost on me.

I'm not apart of the LIVE workshop nor the SE community, so I'm quite clueless what they are doing. I will be pushing my web essay when I get back from holiday next week, but it's basically the usable live programming content adapted for a mass audience. I'm also fi

Yes I think that's it. Good! Will look forward to your web essay, and sorry to disturb your holiday..

Hanging out in a Parisian Starbucks while my wife shops; hardly disturbed.

Well I have to admit this kind of discussion causes me a lot of stress...

If you fancy an excursion to the local countryside I heartily recommend foret de fontaineblaeu/trois pignons, one of my most favourite places on the planet.. Although not when it's raining.

Think of it as training when you have to confront reviewers/practitioners outside of your comfort zone. I happen to come from a background where trial by fire is very common (at Microsoft, in PL, and when I was in grad school). Revolutions are also disruptive, not harmonious; expect a lot of people not to get easily what you are doing if it is new and not very derivative.

I'm a fairly used to having to deal with cross-disciplinary rigour, I did my postgrad work within a research group which included GOFAI gurus, experimental psychologists, musicologists, major lisp hackers and an astrophysicist. But you're right, that doesn't necessarily prepare you for making yourself understood in single disciplinary contexts.

It looks like Sean and you are talking past each other, so I'll repeat what I understood of his question in hope you can help answering.

Sean likes the idea of live coding (instant feedback, direct visualization etc.) and would like to apply it to everyday programming problems: writing a sorting function, analyzing a large dataset, programming a video game, understanding the reason for this painful bug in this large legacy program, etc.

However, the discussion on the blog post you linked mostly, or only, talks about doing music/arts with programming, which is extremely cool and interesting and worth exploring, but not what Sean is mostly interested in. He wonders whether you *also* discussed using "live programming" for the more mundane problems discussed above, or whether this particular meeting was focused on the "artistic performance" aspect of live programming.

This is fairly accurate. Or, perhaps, given the broad participant list, a "what does live coding mean to person X" might also be useful.

I wouldn't use the word 'artistic' as a distinction here, we discussed creativity and performance across pedagogic and industrial contexts, as well as music, animation and textiles.

Yes although creativity and performance was a focus, and a lot of the discussion was framed around music making, we did discuss some of the problems you list.

Writing a sorting function.
Who actually writes sorting functions? :) I guess it could come under educational concerns, which we discussed at length.

Programming a video game.
This is what Fluxus (http://www.pawfal.org/fluxus/) is made for, so yes. Dave has also built game-like live programming languages, and live coding techniques generally seem to apply well in creative development of interactive experiences.

Bugfixing legacy systems.
We didn't really get on to this as far as I know. Software engineering was a major topic though, particularly it's history and theoretical underpinnings.

We did discuss live programming languages though, i.e. live feedback in code, time representation, and other technical issues. We hooked up with VL/HCC although the skype didn't work out too well.

We're currently in the process of summarising the discussion into a report, and tying up loose ends.

Saying something was done but not how or why it was related doesn't give me much to go on. It seems the consensus is emerging that live coding is performance-oriented, if you don't think that is accurate then you'll need to work extra hard in clarifications. I look forward to seeing the report.

The VL/HCC session came out of nowhere and I can't find anything about it. It seems the SE folks are ignoring Hancock (who defined a standard for live feedback) in favor of Tanimoto's levels of liveness, which are descriptive but not at all prescriptive. Sort of the opposite of what we are doing in the PL community.

Sorry, the seminar was conducted in the traditional Dagstuhl way, and is difficult to summarise, but we are in the process of doing that. I'll invite the other participants to take part here though, they may feel able to respond more directly.

Tanimoto's levels of liveness are very useful for supporting discussion.

In our past discussions, I thought we agreed that live coding is focussed on situations where the programmer is interacting with the outside world through their code, and programmer-code interaction is an inner feedback loop. It certainly makes sense to call that "performance", in the Austin sense. To then use the word "performance" to imply that live coding is just about artistic re-appropriation of serious programming language research is linguistic trickery.

So while live music improvisation was the central starting point, the headline aim of the seminar was to find connections with wider fields, including software engineering and computing education. Mark Guzdial gets across the CS motivation for doing this well:
http://computinged.wordpress.com/2013/10/01/live-coding-systems-challenge-cs-to-think-about-expression-again/

Of course, being interested in performance feedback does imply that you are also interested in programmer-code feedback, and to a lesser extent, vice-versa. I'm certainly interested in both live coding and live programming languages.

I don't think Hancock is being ignored, his name was brought up in our seminar and his work is highly relevant. I do think you fundamentally misrepresent his thesis though (unless you changed your view of it during our previous discussion). In particular, you seem to think that he is only concerned with programmer-code feedback, decoupled from the environment, when this is plainly not the case. For example, he explores children learning programming by live programming robots. You have also misunderstood his concept of a "steady frame" as being about frozen time (rather than structuring data in a declarative manner, so that it is continually meaningful and visible, including in response to changes in the environment). Again perhaps you have changed your view, but you have not acknowledged this if so.

By the way, the PL community is bigger than you. You seem to think that "live programming" is only about programmer-code feedback. That is your interest, but Hancock, Victor, the PL researchers at Dagstuhl, the attendees of VL/HCC or LIVE do not all share the same box.

I wrote something constructive here, but then I thought it wasn't really worth it AT&T his point. We wouldn't be at this point at all if you weren't so aggressive about claiming everything was live coding without ever really defining what that meant, and then just making all of us confused.

In the end it is our produced artifacts that will define us, and what we will be judged on. I'm cool with that, are you?

Perhaps someday we will be able to have constructive conversations about what is really happening, but until then we are talking different languages with completely different world views.

I'm still not sure who you are speaking on behalf of (you keep saying "we" and "us" without saying who these people are), but I'm really not claiming that everything is live coding.

I'm differentiating the live coding community's general focus on performance feedback (particularly improvisation with media) with your focus on manipulation feedback. I think this is a useful distinction, and I hoped this would satisfy you.

I don't think this is quite right. Perhaps it would be better to talk in terms of narratives: what are the stories for "live coding" in term of participant experiences. We could compare that to other narratives to determine how they differ. I think we both agree that there is some overlap in technique, which causes most of the confusion.

Yes, going through some stories would be helpful.

I'd also love to get at people's (understanding of their) experience of live coding (using IPA or similar methods).

I feel though that you're treating me as a spokesperson, and expecting me to define a community which is quite diverse and overtly plays with its own definition. I think I'd be much happier talking about my own work, interests and experience, in more specific terms. Maybe this is why we have a problem communicating?

As far as I can tell, you are the main person active in promoting live coding and trying to give it a unified voice in a sea of many practitioners; e.g. through toplap and wiki editing. And wouldn't some consensus come out of Dagstuhl, a clearer story given the diversity of the attendees? My only beef is with live coding labels being applied to work without either explicit buy in from the owner or a clear standard understanding of what live coding is. This is not so much of a problem now, and I didn't want to reopen that debate here (I don't see a need).

I'd be happy to talk about your work, just post new threads, or perhaps we will overlap in some conference or seminar someday. I was just using this trip report thread to tease out more of what happened at dagstuhl, I'm just curious.

Live coding is about changing rules while they are followed. That's clear enough to me.

But you ask "what is live coding from a problem solving perspective", which is difficult to answer. Firstly it depends on the problem domain, and secondly we're talking about creative domains where problems are not well defined, or are changed through the process of being 'solved'.

Lets drop the territorial stuff.

On reflection maybe Victor is focussed on programmer-code manipulation feedback as well, although he does have a performance at the end of one of his recent videos.

Everytime I go out and present my work, I'm definitely "performing" and we could call that an instance of live coding; live demos during talks (I haven't done a talk since 2006 without a demo in it) are a necessity in our field but are just a means to an end.

Hancock and Victor have very similar goals, I almost wonder if Victor was aware of Hancock's earlier work (with Seymour P. no less) and just forgot to ack him. It is also inline with how I frame my research, and why I have difficulty relating my research to what is going on in your community (a case of incommensurability?).

Here is some of my recent output that describes this better.

Hey, that's actually looking pretty usable. Nice work!

Thank you. I'm willing to give lots of demos at Splash to anyone who will be there.

"Performance orientated" can include situations for collaborative learning and shared exploration of a problem, or in more traditional terms, interactions between a programmer and a client.

Another concept brought to our attention by Robert Biddle was the concept of the "Clickety Click - how's about that?" the idea of a programmer sitting working with a client and shortening the feedback cycle to this level of interaction.

Considering programming as a shared exploration of a problem domain (and blurring boundaries between specialisms) is one potential we discussed of livecoding in wider scope. This has already occurred in terms of music - e.g. emergence of livecoders who are musicians first, learning programming enough to do musical performance.

From my perspective one of the interesting things that comes out of these kind of sessions is an understanding of language and environments that are practioner designed and implemented, and used in a social and psychological context that affects the tools. In that sense they add interesting points to the 'zoo of languages', and in a way that is grounded in some real use.

Personally, I don't think I want to dive too deeply into a discussion of the performative aspect this evening. But suffice to say that whilst most of the work I do isn't performative in the same sense as that of the musicians present at the meeting, I think that aspects of performance are embedded in much of the practice of software engineers building more 'traditional' systems. If the study of live coding style performances can contribute to a better understanding of these practices and inspiration for how to build tools for them, that that seems valuable to me, and an oft cited reason for studying 'end user domains'.

So this comes to the question, if I understand it correctly, was there anything that could learnt from such systems for domains other than performative music? For me at least the answer was yes. Off the top of my head and without my notes, there was an interesting discussion of data structures that represented a particular perspective on timing behaviours in systems with both circular and linear time components, there was a discussion of side effects as musicians might talk about them, there was an experiment in 'self-organised' programming, a kind of social problem solving, and there were a number of articulations of immediate use to me e.g. version control supporting "Programming without fear" which is a helpful description of a user experience. It also seems to me to be a promise that we should forefront in the design of version control systems, which we certainly don't succeed at today.

So there was progress on a number of fronts that I think are useful outside performative music. This isn't close to the beginning of a fair summary of all that was achieved in this regard, but I'm pretty confident that I'll find a number of the discussions we had at the sessions useful in my own practice as a language designer and implementer, probably in ways that I'm not even aware of just yet.