That’s the headline for my latest project (with Tomas Petricek), presented at HATRA. [paper] [recorded talk]
With this work I am finally confronting the demon cursing my work: version control. If we are to liberate programming from text we need to make structure editing work, including version control. After all, there will be limited benefit from structure editing if collaboration forces us to return to text editing. It feels like this chronic problem has been dragging me down forever. I’ve spent endless effort trying to handle differencing and merging with embedded unique IDs, but I never got it fully worked out, and it remained as technical “dark matter” clogging all my projects. I finally had to accept that the whole approach wasn’t working, and start over.
I’ve turned to the idea of Operational Transformation (OT), which is how Google Docs works. But OT does synchronization, not version control, so I’ve repurposed and generalized it to support long-lived variants with difference inspection and manual merging. Surprisingly, it seems no one has done this before, and I had to invent a new theory.
The result is “high-level” version control. By observing the history of edits we can do much more intelligent version control. For example a rename refactoring is a single atomic operation that does not conflict with any other, whereas in textual VC it conflicts with every change on the same line as an instance of the name. There is also a big opportunity to simplify the conceptual model of version control, which is frankly an utter disaster in git. Perhaps version control is actually the weak point of the textual edifice, where we might be able to win a battle.
The paper situates our work as reviving the “image-based” programming model of Smalltalk and LISP machines and other beloved systems like HyperCard. Images combined all code and data into harmonious and habitable programming worlds. But the difficulty of collaboration and distribution were major blockers for image-based systems. Because images combine code and data, we must also deal with schema change, which we talk about in the paper. We see schema change as another overlooked benefit to structure editing to help incentivize the move from text.
We have a long way to go towards that vision, but at least this paper is a concrete step. I haven’t published a paper in ages. Thanks to Tomas for helping me reboot.
7 Replies to “Version Control for Structure Editing”
No need to publish this comment (I guess, unless you really want to)… a few typos: search for “combied” and “But he difficulty”
I’m not understanding your text fully but it seems it has touching points with similar issues I have.
For configuration based software using JSON or similar text based configs Git is indeed poorly working.
OT is great but you are right it’s not version control.
Ideally Git should be upgraded to handle it better.
Yeah as someone who has dealt with a binary languages for years (LabVIEW and Allen Bradley PLC ladder) This is always an issue
See also SemanticMerge.com
See Microsoft’s Intentional Programming, from over 20 years ago.
Every declaration has a UUID, edits are transactions on something akin to an AST. This is a better starting point for merging… and then for higher level merge logic on top of that.
looks like I have re-invented same idea https://uprun.github.io/lisperanto/
Comments are closed.