I hope somewhere on the far side of CRDTs, we start trying to model code edits the way humans either do or 'should' do code edits, because treating them as 'anything can change' seems to be the most expensive part of running things like IntelliJ or Webstorm.
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.
I've been interested in livecoding for more than a decade, and participated in both the online and offline Supercollider community.
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".
Music (as a whole, and in an absolute sense) can only be good subjectively. Competency with an instrument or technique can be objectively evaluated, as can whether a piece has mainstream appeal (given some ultimately arbitrary criteria), or if it conforms to the expectations and tropes of a particular genre.
Maybe a more useful way to frame it would be that you haven't come across a live coding performance that you enjoyed or that you found pleasing?
extremely relevant disambiguation that I for sure had never heard about:
> 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:
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.