Expressions of Change: programming with change as a primitive
expressionsofchange.org
expressionsofchange.org
As it says on the website: "The aim of the project is to improve the tools for constructing ever-changing computer programs by putting the changes themselves central in the programming experience." The idea is: if something is a large part of the problem domain, we better make it part of the solution as well.
The results are promising, that is: not ready for production yet by a long shot... but the kinds of things that I expected to work well in the "change as a primitive" world actually seem to work well.
The editor that's part of the project produces, rather than a single structure, a recipy for program construction (or, depending on how you look at it, a history of program construction).
The other parts of the tooling then utilize this history. For example: static analysis may be turned into incremental static analysis (telling you _when_ you made an error in addition to _where_).
Ultimately, the goal it possible to have programs reason about their own history ("historic meta-programming")
That's how you create skynet.
When does a person look at changes? Reviewing effects, reviewing code changes, maybe finding a regression...
Source code alone doesn't pull that together. Also because there's no changelog, reviewing and understanding changes is going to be harder.
If there was a way of matching up all those changes with program effects, it could be interesting. I.e., match up source code diffs with execution diffs. I'm not exactly sure what an "execution diff" is, but I think it could be cool ;)
re changelog: the idea (not in the demo video on the homepage) is to allow for "comments" (analogous with commit messages) to be attributed to arbitrary modifications.
re "program effects": this is indeed one of the ultimate goals (I've done some work on it as well). The idea is roughly that one can distinguish between the effects of a change on the program's structure, and on its behavior. For example, when changing a particular function's implementation the only effect on the program's structure is right in that function, but since the function may be used in many locations, it may change all of those location's behavior. If we know the calling locations (and those functions' calling locations, forming a graph) we can show which parts of the program might possibly be affected by the change.
We can also "look from the other side", i.e. look at a piece of code not just through the lens of when that piece of code changed, but also showing when pieces it depends on (through references) have changed and how.