>The reality of life is that the real world is not immutable. I mean that at two levels. The first is that sometimes people make mistakes and publish things that they very strongly wish and need to change or retract. Pretending that they do not is ignoring reality. Beyond that, things in the real world are almost always mutable and removable because lawyers can show up on your doorstep with a court order to make them so
That's not about what the world is. That's what some people think it should be, and systems (e.g. legal systems) have been created on top of real world to feature this mutability.
Real world is immutable with respect to time. What happened, happened; you can't change it without a time machine. You can't just unpublish something, you have to actively work to destroy all practically accesible traces of it (and fight the people with interest in preserving these traces).
So a better, more accurate way of phrasing GP's point would be: systems designed by humans are mutable by design. Physical reality is immutable with respect to time and causality.
> Real world is immutable with respect to time. What happened, happened; you can't change it without a time machine. You can't just unpublish something, you have to actively work to destroy all practically accesible traces of it (and fight the people with interest in preserving these traces).
That definition doesn't make any sense. Mutability necessarily requires time to drive a change - no time passing, no mutation. Also, you are claiming that immutability is equivalent to irreversibility and the arrow of time, which I also think is a bit wonky.
> Mutability necessarily requires time to drive a change - no time passing, no mutation.
The time that's required for mutability is the real time, the time outside of the system considered. You can mutate events recorded within a system. You can't unhappen events themselves.
> Also, you are claiming that immutability is equivalent to irreversibility and the arrow of time, which I also think is a bit wonky.
Actually, immutability is even more evident without the arrow of time; if world(t+1) = f(world(t)), then world(t) = f^-1(world(t+1)); f and f^-1 are themselves immutable.
This is silly, though. Yes, facts can be thought of as stationary in time. No, no system is stationary in time. Even the ground you are on is moving.
So, can you record facts against time in your database? I mean, go for it. Might even be useful in many realms. Doesn't magically make you able to operate on something frozen in time, though.
It seems like the opposite is true of verbal communication? If it wasn't recorded, there is rarely evidence of what was said for someone else to find.
Although there is often some evidence, it's unusual for a complete history of an event to be preserved in perfect fidelity, as it's sometimes modeled in a computer.
> If it wasn't recorded, there is rarely evidence of what was said for someone else to find.
There are rarely "practically accessible traces" present. But the information about what was said itself radiates at the speed of light. There may be evidence present for a dedicated enough investigator. But even more important is the obvious - you can't just unsay what you said. When you say something to someone, you change their state. They'll remember what you said, or what they felt. You can't roll that back.
> Although there is often some evidence, it's unusual for a complete history of an event to be preserved in perfect fidelity, as it's sometimes modeled in a computer.
It is a qualitative change on the social level; it's absolutely not a change at all on the physics/causality level.
Mutability works in human-designed systems. For instance, if I say something to you, and there was no recording of it, then I can later deny we talked, and from the legal point of view - a point of view of an artificial system built on top of physical reality - the conversation did not happen. This doesn't change that a) it did, and b) both of us know it did.
I don't think that the exciting part about immutability in large scale distributed systems is immutability itself, but rather referential integrity--particularly from names to arbitrary data (usually seen as cryptographic hashes that function as pointers).
If that reference is mutable then there needs be some authority that handles which names resolve to which data at which times. This makes it difficult to determine at time t if the bits you received at time t-1 were the right ones for some name.
In immutable designs the complexity of deciding "which version?" Is moved up in the stack (where the answer is typically mutable). In many cases, pushing this complexity out to the user is indeed the right thing to do.
Sure, the ability to resist a government's desire for censorship _might_ be a design goal, but there are other reasons to prefer immutability.
E.g. IPFS can be seen as a mostly immutable distributed system (due to content hash based addressing). But it can fully comply with thinks like copy right or privacy related take down notices. Mainly because it only guarantees immutability of existing data, but not that the data will stay existing. (At the same time it provides a re-sharing framework which can make it really hard for lawmakers to effectively enforce such polices if people want thinks to stay online).
I prefer to adopt Daniel Dennett's model of 'useful fictions' when trying to talk about what the world 'is'. The question for developers isn't if the world is immutable or mutable, it's if mutability or immutability are useful concepts.
To ask if the world is mutable is like asking if money is real or if the colour red is real. Does it make more sense to talk about RGB values or colours? The only reasonable answer is 'it depends'.
It depends on what aspect or properties one is interested in and what lens is best suited to solve problems or which one personally finds most insightful. The world can be modelled as an immutable sequence of state transitions or as a place full of stateful objects, there isn't any clear answer and programmers shouldn't be too literal about what they perceive the problem to look like but rather think about what toolbox is most useful.
I agree with that and therefore think immutable is not a useful abstraction as it does not approximate how things appear to be in what we perceive as real.
There are many domains where immutability makes intuitive sense. Accounting and bookkeeping for example, which is a huge domain within software development. A Git history is essentially a model of the world as a history of immutable states, and what we care about is the transition from one state to the next and its difference, as well as an accurate representation of each past state. But one name or ID is only ever associated with one state.
It would be really horrible practise if accountants or version control systems would mutate state and overwrite history. Another domain where immutability is useful for this reason is concurrency, where it avoids a lot of conflict.
Isn't that just a function of how you choose to perceive? For example, the water in a river, and our skin cells are constantly replacing themselves, even though it might not seem that way--what I mean is, maybe one's epithelium is more like an immutable structure, each time displacing the one that came before. Or consider atoms, which sort of have immutability as a core concept.
Except that there is no such thing as World(time). We don't live in a Newtonian world, we live in a relativistic universe. Time doesn't elapse at the same rate in every location, it depends on gravity and the speed you're moving at. I'd argue that since time is a local phenomena, the mutable universe interpretation makes a lot more sense.
> The first is that sometimes people make mistakes and publish things that they very strongly wish and need to change or retract. Pretending that they do not is ignoring reality.
Really? I'd say regardless what their wishes might be, pretending that they can is ignoring reality (at least in some cases). You change or retract things as you do in accounting - by issuing amendments. Not by pretending you never published something, but by updating what you published (i.e. publishing a new version).
> Beyond that, things in the real world are almost always mutable and removable because lawyers can show up on your doorstep with a court order to make them so, [...] If the court says 'stop serving that', you had better do so.
How does that have anything to do with immutability? Immutability is not "The president is Obama", it is "At 01 Feb 2020 my belief was that at 01 Feb 2016 the president was Obama". You can trivially say that "At 01 Feb 2020 my belief was that at 01 Feb 2020 the president was Trump" without contradicting the previous statement. You can even forget what your belief was at 01 Feb 2020. And if the ministry of truth knocks on the door, you might end up to believe, at 01 Feb 2025, that at 01 Feb 2016 the president was Trump. This way, you satisfy the ministry's desires, without violating immutability in any way.
That's an idealistic argument. Sometimes you just need to delete things and there's no negotiation possible.
Whether that makes sense to you or not as an engineer or scientist doesn't matter much. There are tons of things that humans want that "don't make sense" but that you need to conform to regardless. A great example of this is typically the law.
"Immutable" does not preclude deletion, that's what I'm saying. Indeed, to delete something can simply mean to publish a new version with no content. If there's no reference to the old version, it will get 'garbage-collected'/ 'forgotten' by the system.
Looking at immutability wrt. immutable data in the database/at rest then yes that a problem. Same if you
build a system which can't be updated.
I just don't see how many other cases of immutability have anything to do with it (like general purpose immutable data structures, statically fixed data structures, or static linking). I mean you can always change your code to comply with changes, and I would be very irritated if people believe they can put put code out into the world and never need to update it (but _not_ modify it, updating means replacing it with a mostly similar new system while carrying over all data).
Through as a side not: GDPR deletion request basically have the effect that any event sourcing system which doesn't has (perma-) deletion features is unlawful to use (if you process any personal data). It also means that soft deletion is not always lawful wrt. personal data.
Now for some event sourcing systems that is quite a problem. Some might cope with it through snapshots which "compact" the state and as such can have perma deletion effects if the events before the snapshot are deleted, but that only works if you can do so every week or so or you will not be able to keep with deadlines. Given that some systems want to keep logs longer than that this _is_ a problem which can lead to major additional cost if you ran into it.
Per-record keys where the key can be deleted (this is a hard delete as your system can no longer access the data).
Keep "sensitive" info out of messages (credit card stuff, PII, secrets?, whatever), events have pointers to a store just for this. All code that accesses sensitive data has to have guards in case the lookup fails.
Deletion is really interesting and forces its way into your domain. For example you might be in a position where you have to delete all info about someone except their payments because AML forces you to keep those for X years.
Readit News
>The reality of life is that the real world is not immutable. I mean that at two levels. The first is that sometimes people make mistakes and publish things that they very strongly wish and need to change or retract. Pretending that they do not is ignoring reality. Beyond that, things in the real world are almost always mutable and removable because lawyers can show up on your doorstep with a court order to make them so
That's not about what the world is. That's what some people think it should be, and systems (e.g. legal systems) have been created on top of real world to feature this mutability.
Real world is immutable with respect to time. What happened, happened; you can't change it without a time machine. You can't just unpublish something, you have to actively work to destroy all practically accesible traces of it (and fight the people with interest in preserving these traces).
So a better, more accurate way of phrasing GP's point would be: systems designed by humans are mutable by design. Physical reality is immutable with respect to time and causality.
That definition doesn't make any sense. Mutability necessarily requires time to drive a change - no time passing, no mutation. Also, you are claiming that immutability is equivalent to irreversibility and the arrow of time, which I also think is a bit wonky.
The time that's required for mutability is the real time, the time outside of the system considered. You can mutate events recorded within a system. You can't unhappen events themselves.
> Also, you are claiming that immutability is equivalent to irreversibility and the arrow of time, which I also think is a bit wonky.
Actually, immutability is even more evident without the arrow of time; if world(t+1) = f(world(t)), then world(t) = f^-1(world(t+1)); f and f^-1 are themselves immutable.
So, can you record facts against time in your database? I mean, go for it. Might even be useful in many realms. Doesn't magically make you able to operate on something frozen in time, though.
Although there is often some evidence, it's unusual for a complete history of an event to be preserved in perfect fidelity, as it's sometimes modeled in a computer.
There are rarely "practically accessible traces" present. But the information about what was said itself radiates at the speed of light. There may be evidence present for a dedicated enough investigator. But even more important is the obvious - you can't just unsay what you said. When you say something to someone, you change their state. They'll remember what you said, or what they felt. You can't roll that back.
> Although there is often some evidence, it's unusual for a complete history of an event to be preserved in perfect fidelity, as it's sometimes modeled in a computer.
It is a qualitative change on the social level; it's absolutely not a change at all on the physics/causality level.
Mutability works in human-designed systems. For instance, if I say something to you, and there was no recording of it, then I can later deny we talked, and from the legal point of view - a point of view of an artificial system built on top of physical reality - the conversation did not happen. This doesn't change that a) it did, and b) both of us know it did.
If that reference is mutable then there needs be some authority that handles which names resolve to which data at which times. This makes it difficult to determine at time t if the bits you received at time t-1 were the right ones for some name.
In immutable designs the complexity of deciding "which version?" Is moved up in the stack (where the answer is typically mutable). In many cases, pushing this complexity out to the user is indeed the right thing to do.
Sure, the ability to resist a government's desire for censorship _might_ be a design goal, but there are other reasons to prefer immutability.
E.g. IPFS can be seen as a mostly immutable distributed system (due to content hash based addressing). But it can fully comply with thinks like copy right or privacy related take down notices. Mainly because it only guarantees immutability of existing data, but not that the data will stay existing. (At the same time it provides a re-sharing framework which can make it really hard for lawmakers to effectively enforce such polices if people want thinks to stay online).
To ask if the world is mutable is like asking if money is real or if the colour red is real. Does it make more sense to talk about RGB values or colours? The only reasonable answer is 'it depends'.
It depends on what aspect or properties one is interested in and what lens is best suited to solve problems or which one personally finds most insightful. The world can be modelled as an immutable sequence of state transitions or as a place full of stateful objects, there isn't any clear answer and programmers shouldn't be too literal about what they perceive the problem to look like but rather think about what toolbox is most useful.
It would be really horrible practise if accountants or version control systems would mutate state and overwrite history. Another domain where immutability is useful for this reason is concurrency, where it avoids a lot of conflict.
you can model mutation on top of values and in fact immutable systems do this
Really? I'd say regardless what their wishes might be, pretending that they can is ignoring reality (at least in some cases). You change or retract things as you do in accounting - by issuing amendments. Not by pretending you never published something, but by updating what you published (i.e. publishing a new version).
> Beyond that, things in the real world are almost always mutable and removable because lawyers can show up on your doorstep with a court order to make them so, [...] If the court says 'stop serving that', you had better do so.
How does that have anything to do with immutability? Immutability is not "The president is Obama", it is "At 01 Feb 2020 my belief was that at 01 Feb 2016 the president was Obama". You can trivially say that "At 01 Feb 2020 my belief was that at 01 Feb 2020 the president was Trump" without contradicting the previous statement. You can even forget what your belief was at 01 Feb 2020. And if the ministry of truth knocks on the door, you might end up to believe, at 01 Feb 2025, that at 01 Feb 2016 the president was Trump. This way, you satisfy the ministry's desires, without violating immutability in any way.
Whether that makes sense to you or not as an engineer or scientist doesn't matter much. There are tons of things that humans want that "don't make sense" but that you need to conform to regardless. A great example of this is typically the law.
https://www.destroyallsoftware.com/talks/boundaries
Some problems are more easily dealt with using tools like immutability, or mutation for that matter.
as with all things in software - it depends.
I just don't see how many other cases of immutability have anything to do with it (like general purpose immutable data structures, statically fixed data structures, or static linking). I mean you can always change your code to comply with changes, and I would be very irritated if people believe they can put put code out into the world and never need to update it (but _not_ modify it, updating means replacing it with a mostly similar new system while carrying over all data).
Through as a side not: GDPR deletion request basically have the effect that any event sourcing system which doesn't has (perma-) deletion features is unlawful to use (if you process any personal data). It also means that soft deletion is not always lawful wrt. personal data.
Now for some event sourcing systems that is quite a problem. Some might cope with it through snapshots which "compact" the state and as such can have perma deletion effects if the events before the snapshot are deleted, but that only works if you can do so every week or so or you will not be able to keep with deadlines. Given that some systems want to keep logs longer than that this _is_ a problem which can lead to major additional cost if you ran into it.
Per-record keys where the key can be deleted (this is a hard delete as your system can no longer access the data).
Keep "sensitive" info out of messages (credit card stuff, PII, secrets?, whatever), events have pointers to a store just for this. All code that accesses sensitive data has to have guards in case the lookup fails.
Deletion is really interesting and forces its way into your domain. For example you might be in a position where you have to delete all info about someone except their payments because AML forces you to keep those for X years.