Elm, Atomist & Semantic Version Control
Some thought-provoking synchronicity yesterday afternoon:
Jessica Kerr (@jessitron) announces that she’s going to work full time at Atomist, which led me to this video:
Atomist is a code generation tool, similar to Rails’s scaffold or Yeoman; the main difference is that it’s intended to do small transformations on arbitrary existing code instead of just generating new code. React people may have some relevant experience with this sort of thing via codemods.
Meanwhile, Dan Abramov discovers that he loves git rebase:
I was reminded then that the “time-travel debugger” that showcased the Elm Architecture (and inspired Redux) is quite similar to the Git model, just at a much smaller scale. Both are essentially change logs, and one can navigate to any point in the history, or alter the history altogether, by selecting which changes to apply.
The primary difference between Git and Elm/Redux is that the latter are deeply concerned with the intentions of changes, while Git is only concerned with the implementation. Elm and Redux take their cues from Event Sourcing: the source of truth is the action that triggered the change; the state is created by and can be reconstructed from the replay of these actions. The actual state manipulation is done separately and orthogonally by update (in Elm) or reducer (in Redux) functions; ideally new features can be added by modifying or creating new reducers without altering existing events.
Git, on the other hand, doesn’t care about the meaning of changes; everything is just a diff upon the previous state. The intention of a commit is hopefully reflected in the commit message, but no one would try to reconstruct the state from commit messages alone. So I wondered: what would it take to make that possible? If one were to make a “semantic version control system”, where the actual code could be reconstructed by interpreting high-level commands, what would that look like?
It would look a little bit like Atomist.
The Atomist editors — the code generating functions — are reducers: they take a command and a previous state and return the next state. The scaffolding commands are the events: they communicate the programmer’s intent without specifying the implementation details. Theoretically, this means that one could update their code generators, re-run the command history, and get conflict-free upgrades of their whole codebase.
Of course, we’re a ways off from that “theoretically” being a “practically”. But what happens when it is practical? I’m intrigued by how it further operationalizes the development of software, such that the process of writing code can benefit from automation just as building, deploying and serving code does. Today I think back to my days of live-editing sites over FTP and marvel how I ever got anything done; which of my current everyday practices will make me cringe in the years ahead?
