Realtime annotations and visualizations in live coding performance (2018)

I almost always check out a file that actually runs and passes tests, which means I started from a coherent and valid file. Then I break that file, by inserting or removing a concept from it. Most of the time I'm going to end up with a file with a new logical block in it, and all of the other blocks returned to their initial state.

So instead of maybe treating the entire file before the edit as valid, and the entire file after as garbage, we should be trying to preserve as much of the semantics of the original file that we can still locate in the new file, and treat the bit in the middle as the garbage.

You can especially notice this in languages where private helper methods tend to migrate to the bottom of the file instead of up to the top. Autocomplete is basically useless until you start refactoring the new code.

This article is about having an audience of 10+, but we haven't even really solved an audience of 1 or 0, and I suspect at least 80% of the problems are shared between them.

From an artistic standpoint, I think the greatest obstacle to creative expression is the lack of popular familiarity with basic programming concepts. If your audience can't tell what you're going through as you perform, I think it's difficult to move people.

This is an interesting attempt to make such performances more accessible. But I wonder if livecoding will remain niche until such time as the general public becomes "code literate".

> in this essay I will use the term 'live coding' to refer to the digital arts practice, as opposed to live programming more generally.

and following the "live coding" hyperlink yields:

> Live coding is a new direction in electronic music and video, and is getting somewhere interesting. Live coders expose and rewire the innards of software while it generates improvised music and/or visuals

so, whew, all those folks who say "project name collision!" got their beer held :sob: