4 ms·
This notion of change seems to conflate a lot of ideas. Knowing that something has changed is different than being able to replay the change. And once you hav
by kenjackson 14y ago
This notion of change seems to conflate a lot of ideas. Knowing that something has changed is different than being able to replay the change. And once you have a system that cares so much about time haven't you given away half of the programming advantage of functional programming? Sure, there may be immutability, but you trade that for having to manage state explicitly in immutable objects. That just sounds like a whole new class of "race conditions" (you passed me this state object, but someone else just created that state object with the same identity).
- Dylan16807 14y agoIt does seem to mix a lot together. And the title is easily proved wrong. You can store data as a live object and a linked list of diffs to go further back in time. This is how the git pack file and many backup systems work.
- Robin_Message 14y agoThat is just an efficient way to store the original object and linked list of diffs to get to the current object (assuming accessing the current object is more popular). Note that if you store the original and the diffs, those things are all immutable. Indeed, that is how git works in general – recording changes as immutable commits, and having one or more heads which point to the new immutable commit.
- Dylan16807 14y agoRight, you can flip it to make everything immutable, but then accessing the current object is O(t).
- quorn3000 14y agoAnd then you have SourceSafe
- eru 14y agoI understood that git stores snapshots, and not diffs. At least conceptually.
- DigitalJack 14y agoIt does both.
- Dylan16807 14y agoConceptually it's snapshots. At the lower level of pack files it's diffs.