@jarm: > There's "live coding" meaning changing a running program, and "live coding" meaning artistic programming as performance. The latter definition assumes the former as well, but the former not the latter. (I'd reply in a thread, but it seems too late for that in this conversation.) I think there's a distinction here as well, though I'm struggling to articulate it. Here's one attempt: it's about the size of the input space. A programming performance like in the Alexandra Cardenas demo above, or @yaxu's demo at https://futureofcoding.slack.com/archives/CCL5VVBAN/p1575367625254000 has a constrained input space. From instant to instant, any inputs entering the program are stable. Only code changes cause behavior changes. This is not true of "real programming," to put it mildly. If you introduced the possibility of inputs changing, the nature of the programming performance would be forced to change. It may take many different inputs to internalize the behavioral effects of a change to the program. Either you'd end up spending a lot of time on one snapshot of code (which seems like "real programming") or you'd need new visualizations for the input space (which seems really interesting) which show interesting features in a way that is amenable to System-1 processing by the visual or auditory cortex. The latter seems like an open research problem in general. The term "real programming" is intended humorously; I'm pointing just at the status quo among programmers. No live programs were maligned in the making of this comment. But I'm now weakly inclined to think these two categories have more contrasts than similarities. cc @alltom @jonathoda

@Kartik Agaram I do not understand what you mean by "inputs". I think you have a misconception. > From instant to instant, any inputs entering the program are stable. AFAIK the tidal programs in the linked demos have no inputs. They only have output, which is the music that you hear. The program is outputting a music loop, which endlessly repeats. When you modify the code, you change the musical elements within the loop. Because this is live programming, you instantly hear the results of your code change in the musical output.

No I understand than. No inputs is a special case of stable inputs. For example you can think of the song being spliced in the final line as an input that's being repeatedly looped.

You said

Only code changes cause behavior changes. This is not true of "real programming," to put it mildly.

Since there are no inputs, how can anything other than a code change cause behaviour changes? So this part doesn't make sense.

If you introduced the possibility of inputs changing, the nature of the programming performance would be forced to change.

I've seen live coding performances where the input is a video feed, and the output contains a transformation of the video feed. I don't see how this changes anything.

It may take many different inputs to internalize the behavioral effects of a change to the program.

Now maybe we are getting somewhere. If the output of the program integrates the inputs over time, then live coding becomes costly to implement, because to maintain fidelity, you might have to redo the integration over the input history on every code change.

or you'd need new visualizations for the input space (which seems really interesting) which show interesting features in a way that is amenable to System-1 processing by the visual or auditory cortex.

Not sure what this means.

Me: > Only code changes cause behavior changes. This is not true of "real programming," to put it mildly. You: > Since there are no inputs, how can anything other than a code change cause behaviour changes? So this part doesn't make sense. Live programming doesn't typically have inputs. Status quo programming is entirely concerned with inputs. Functions often return dramatically different results depending on their inputs. If a live-programming system had inputs, and if it changed dramatically based on its inputs, it would take a long time to get a sense for how a given change to the code modified its behavior. For example, there may be broad swathes of inputs that have no visible difference in output for some code change (especially if it's guarded by some predicate). This seems like a big contrast between the two categories. Does that help? If not I'll throw in the towel..

Thanks for this @Kartik Agaram! I am also slightly confused as to what you mean by inputs.

From instant to instant, any inputs entering the program are stable. Only code changes cause behavior changes. This is not true of "real programming," to put it mildly.

Do you mean "inputs" as in, in "real programming" (😄) you might have a database entry populating the program, or a user filling in text fields etc? i.e. the data that is running through the program?

Tidal patterns have as many inputs as you like, and always have at least one - time

> Live programming doesn't typically have inputs. Status quo programming is entirely concerned with inputs. Live programming is not domain specific. Smalltalk is a general purpose live programming environment, for example. And yes there are inputs. In the Bret Victor video where he is live programming a super-mario style video game (at 10:45 in the video), the inputs are the keyboard inputs he is using to play the game. Bret switches between playing the game and editing the code. He doesn't edit the code and play the game simultaneously: either the inputs or the code are being held constant at any given time. Inventing on Principle If I was live coding my Curv compiler, the input would be the program I am compiling, and the output would be the generated code. I would hold the input constant while live editing the code (maybe I am debugging a code generation problem for a particular program). Then once I have a code change I like, I might start changing the input program to see how the output varies using the new code change.

> Live programming is not domain specific. Smalltalk is a general purpose live programming environment, for example. @Doug Moen this is very frustrating. I was literally responding up top to a comment about how "live coding" means two things, trying to carefully create new sub-categories to separate Smalltalk from performance programming. Then I fell back into calling the latter category "live programming" when responding to you. > 'Traditional' programming doesn't have any inputs or outputs, as the code isn't running @yaxu Very funny, but see my comment above. Goal of this sub-thread was to distinguish two categories of live programming. It is bloody well running. --- @jarm Yes, reading from a database and noticing that one row belongs to a premium customer and requires whole new buckets of logic to be applied to it is an example. Maybe I'm talking about control flow? Status quo live programming has lots of deep nested control flow, just like status quo non-live programming. But performative programming can only have so much control flow, lest it overflow the performer's and audience's brains.

@Kartik Agaram Regardless, live coders take input, so I think your dichotomy doesn't work. I think there is no technical difference, only a cultural one. It'd be interesting to bring these cultures together.

My original statement was "it's about the size of the input space." So we're still talking past each other. Ok, most code I work with doesn't run. Ha ha. But I'm running it in my head, so it's possible in principle to talk about tools for running it. Performative programming is all about the audience appreciating how changing symbols changes the performance. Am I capturing it right? Otherwise it just falls back into listening to U2 or whatever. At the moment I can't imagine how more tools will support the audience appreciating the sorts of complex regimes of behavior that Smalltalk or yes Unix has to deal with. I absolutely agree that there's value in bringing these cultures together. But there's also value in understanding why they may have distinct needs.

@Kartik Agaram

performative programming can only have so much control flow, lest it overflow the performer's and audience's brains

I see where you're coming from, but I tend to agree with @yaxu that in live performance that control flow likely exists but has been 'nested' somewhere the programmer doesn't have to directly deal with it in the moment. This has the same effect of minimising cognitive overhead.

@Kartik Agaram there isn't agreement about why live coders project. One argument is to allow audience members to read the code in order to engage with the music better in some way. Another is to just show what you're doing, so people don't feel alienated/don't just see the back of your laptop screen. I tend towards the latter.

How about this reinterpretation of what you've been getting at @Kartik Agaram: in artistic performance programming, the data of the program come largely but not exclusively from the performer themselves or artistic decision they've made (load this sample, create this synth, process visuals in this way), whereas in traditional programming the data comes 'from another' either made up or real user

How about someone live coding a 3D printer. They don't have an audience, but are responding in real time as the print head moves around their creation, which (for the sake of argument) is an experimental medical instrument rather than a sculpture. I think maybe the 'art' and 'audience' in live coding is distracting us a bit. The interesting part could be more about using a live coding environment as an end-user, live interface, to think and feel in the world.

@jarm That's certainly part of it. Now that I focus on that part, has anyone made dueling or battling performances where two people jam together? I'm imagining a cursor that spends some time with either/each performer.

There have been live coding battles, there's a strong tradition of it in the demo scene

@Kartik Agaram I would describe the scene as heavily invested in real-time collaboration. some very good studies coming out of it. I should start that reading list..!

I’ve perceived performative live coding as being a situation where the control flow is split between the human and computer, whereas in the other type of live programming at the start of the thread, the goal is still to push all the control flow into the computer by the end.

Time sharing one cursor strikes me as quite confrontational, could be made fun, but more often in music practise I see people tending towards giving each other their own space

Doesn't have to be confrontational. I was imagining it as kinda like improv. "Yes, and.."

Reminds me of https://studiomoniker.com/projects/do-not-touch

@jarm I dunno. 😅 Immediately after pressing send I started thinking about how people make decisions all the time while using software, so I don’t know if I said anything useful. If it requires defining the difference between programming and non-programming, then I think probably not. I took too long to check my email one week and missed my invitation to Dynamicland, but my impression is that when you’re there, you’re never meant to “put down the chisel,” which sounds performative to me.

@yaxu

there isn't agreement about why live coders project. One argument is to allow audience members to read the code in order to engage with the music better in some way. Another is to just show what you're doing, so people don't feel alienated/don't just see the back of your laptop screen. I tend towards the latter.

I don't get this distinction. If people see the front of your laptop screen but can't understand what's on it, is that really less alienating than the back of your laptop screen? (On one level my whole schtick for the last few years is that open source is only open to the extent people read the sources.) --- I went back and reread this whole conversation, and the key idea here seems to be this:

..it's a shame ..that future of coding / programming language experience design etc has so carefully ignored all the work in the live coding community..

I agree that we have failed so spectacularly to get out of the building and get feedback from prospective end-users that the danger I was pointing out (of over-training on the needs of the live-programming community) is overblown and not worth thinking about. Carry on!

@Kartik Agaram the alienation is more to do with hiding what you're looking at/doing, rather than needing to understand what it is exactly you're doing. imagine going to a guitar concert and the player is behind a blackout curtain but you can just see their head!

In "Tools for Conviviality", Ivan Illich calls anti-convivial tools "manipulative". https://co-munity.net/system/files/ILLICH%201973_tools_for_convivality_1.pdf

Ah so I'm wrong, all computer programming is in the manipulation-driven category

@yaxu That's multiple cursors rather than people taking time with a cursor, I don't know if that's been done

That was first done in 1968 in the NLS system. If you want to see where the mouse, windows, hypertext, video conferencing, and collaborative editing with one cursor per person all came from, check out "The Mother of all Demos". The collaborative session starts about 1h16m into the video. <https://www.youtube.com/watch?v=yJDv-zdhzMY>

I'm aware of the mother of all demos!

@Kartik Agaram

Doesn't that happen all the time in the nose-bleed seats in a concert?

All I'm getting at is that the motivation to project code in a performance, is more often primarily a symbolic act of sharing and openness on the part of the performer, acknowledging the detrimental social and musical effects of obfuscation that usually take place during laptop-based performance. For more see <https://toplap.org/wiki/ManifestoDraft> & <https://github.com/Algorave/guidelines/blob/master/README_en.md>. There are other benefits of this sharing act that include actual comprehension of code, but no one believes that people are coming to gigs/concerts purely to read code, or to celebrate it as a spectacle. See also Kim Cascone, "Laptop music-counterfeiting aura in the age of infinite reproduction", 2002: <https://scholar.google.com/scholar?cluster=11273167955509493610>