
Expressions of Change: programming with change as a primitive - vanschelven
http://www.expressionsofchange.org/
======
vanschelven
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.

------
mplantsheer
If I understand correctly this project intends to integrate a change
management editor meta file as part of the language itself?

~~~
vanschelven
You understand correctly.

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

~~~
machiaweliczny
> programs reason about their own history

That's how you create skynet.

------
jack9
Ponylang has a type system that is similar in concept. I really like it,
although the ecosystem is still primitive imo.

~~~
vanschelven
Interesting. Just to be sure: are you talking about behaviours?
[https://tutorial.ponylang.org/types/actors.html#behaviours](https://tutorial.ponylang.org/types/actors.html#behaviours)

~~~
jack9
Reference Capabilities are part of the type system. E.g. iso, val, ref, box,
trn

------
ianbicking
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
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.

------
karmakaze
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.

