Author here, here to answer any questions. This project is part of the output of my sabbatical. I decided to work on something a bit more theoretical, and close to my heart, after spending considerable time on a successful B2B SaaS venture (buy-out by my partner).
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")
I like the motivation – including a programmer's active concerns in language design – but I'm not sure of the purpose of this change tracking.
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 motivation: I suppose this depends on what you're used to. Having worked on a single product for over 6 years I did find myself in blame/praise and log mode quite regularly. And on a global scale, 6 years is quite young.
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.
This is so amazing. I've often wished I could keep refactoring commands on a git branch that could be replayed on a future version of the program. This allows that and much more.
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.