3 ms·

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 pers

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 ;)

vanschelven 9y ago
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.

vanschelven 9y ago

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.