There is a quite pervasive idea in modern software. It is the idea of history and undo/redo. It is often a must that software manages state history and transition back and forth.
I have a simple idea, maybe not new, but one I haven’t seen deployed anywhere. – On second thought, yes – in version control software.
The idea is to extend history to become revisionist. Now how does one do this? The idea is quite simple. A history is sequential, but a revisionist history is hierarchical. That means that it forms a more expressive graph.
Say in an image processing software, in this setting one wants to be very experimental and try out things, but one does not want to be punished for maning the wrong steps. So one often goes back and forth between ideas. But even in this setting, once you go back and then try a new idea, the old idea is gone.
Instead of this mind-limiting software, we need more tree-shaped history. That is, history where one can go back and rewrite history – without overwriting the future – so to speak. So in simple terms it means
- a, b, c, <undo>, d => a, b, d
- a, b, c
- a, b, d
- a, b
So all paths are preserved. The user is free to walk with impunity. No information is ever lost.
One may see the tree history as a functional rewrite. In functional programs, one never destructively updates (or never unsafely at least), instead, what one does, is to use pointers – data is reused, not destroyed. This means one can safely share data because it is never destructively updated. It may be garbage collected, when no longer used, but it isn’t destroyed as part of an update because that simply isn’ t updated, generally speaking.
It would be nice to see such an approach applied more widely and with database backup.
The next step would be to imagine merging parallel branches, in effect to use graphs. But that’s a topic for another time.