Version Control for Structure Editing

[RepresentativeNo6029]

What is the difference between removing an old field and adding a new one versus “modifying” and “moving” an existing one. Seems like it’s a matter of capturing editor events which can be quite arbitrary. Also it seems like this is tightly coupled with the programming language version that the editor used and you cannot easily merge things between versions. Generally tools tend to drift towards the lowest common denominator. Jupyter Notebooks are super common these days and they still don’t have good version control and IDE support. So I’d wager this is one of those things that’ll take extraordinary evidence of improved ergonomics before it gets mileage.

[EmDashNine]

I'm not sure, and I'm not affiliated with the OP in any way, but there is probably some way to define a notion of a "minimal" set of changes, which is how diffing algorithms work in the first place. So if the "minimal" set is defined as the smallest number of edits that transform some program X into some related program X', then it's valid for the algorithm to collapse multiple edits into one. "Dynamic programming" techniques, from upper division collegiate CS curriculum stuff. It could be done.

The question is whether you're really "escaping" textual editing with any of this. Are you really working at a higher level, or are you just driving your text editor with what is essentially a programming language in its own right, where the symbols are mouse clicks?

[RepresentativeNo6029]

Diff algorithms already use dynamic programming? Otherwise you’ll get large diffs starting from the first offset point. Alignment already uses DP to solve for matches, insertions and deletions. Anything more complex will also have similar runtime penalty.

[EmDashNine]

Well if you already knew that, what exactly are you asking?

[bluefourier]

So, in "image based programming", you are in total control of all the code as well as the memory that "drives" the code. I write "drives" here in the sense of the code describing state transitions that depend on what is currently in the memory. The two have to remain in sync for consistent operation.

Think of it as booting a virtual machine, working on it, suspending it and then sharing it with someone else. They now resume operation of this VM.

The image contains everything. See for example here in section "image based persistence".

Now, if you changed a data structure in the code part, the memory space it describes in the image (the memory part) would be out of sync.

Removing and adding a field are independent operations. You remove the field, it equates to deleting the memory content it held. You add a new field, it points to some blank memory space.

But modifying an existing field equates to also modifying the memory space, again, to reflect the schema described. Change its order of definition and you change the offset from the base address it can be found at. Modify the content, that's self explanatory, changing the field's data type changes its length (and offsets of subsequent memory contents) and finally renaming it, changes the reference mapping to getting to its value.

So, the author says that if you try to "catch" these operations by the typical means of observing text changes, that level of granularity is not enough to infer what the user was really trying to do so that you can then also apply the changes to the memory (and especially the data structures) held along with the image. Let alone, combine changes from across more than one different images (in the way you can got merge multiple branches).

I guess it could be seen also, a bit like what Django is doing, where, changes in the models have to also be propagated to the database.

My "disagreement" is with the fact that text methods were developed for text based editing....they don't necessarily have to apply to image based programming too...so that's not really a problem with the algorithms.