The real world is mutable – consequences for system design | Hacker News Reader

The real world is mutable – consequences for system design

utcc.utoronto.ca

39 pointsash40 comments

No, it isn't.

>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.

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.

Yes, many things can't be unsaid, but it's still going too far to say that we know what happened. Human memory is far from reliable, so we don't necessarily know or agree on what happened. This is assuming the listener even heard it correctly.

> 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.

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.

I can only agree,

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.

Or is it, because physics!

you can model mutation on top of values and in fact immutable systems do this

The world (space-time state) is immutable. World space state is a pure function of time. If you call World(time) you always get the same answer.

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.

Just because the universe is relativistic doesn't mean that we can't model it. Mathematics is inherently immutable --- this is why describing programming language semantics requires the introduction of something "extra" (a state monad, hiding the mutability inside the operational / denotational semantics, whatever).

We _do_ have a mathematical model of the universe --- the differential equations that govern space-time evolution describe the universe in a pure fashion: universe(t+1) = f(universe(t)).

No, you're missing the point. There is no such thing as world(time), but there is world(location, time). If you don't respect that, you'll wind up with unsustainable system designs like using atomic clocks to guarantee consistency.

I think the problem here is the definition of "time".

You are talking about a relativistic time and they are talking about an absolute global time.

I don't know if it makes sense in some kind of way to talk about something abstract as a global time in any way.

If the global absolute time goes on for 1 second, some peoples relativistic time went on more or less than a second. Can we measure this abstract concept of time? Even if it made some kind of philosophical sense?

Relativistic time is a real thing in distributed systems, even without worrying about einsteinian relativity; the premise of physics relativity is that perfect synchronization is impossible and that is highly analogous to the impossibility to perfectly synchronize nodes in a distributed system.

There is a nice analogy between causal relations in special relativity and in asynchronous distributed systems, but it is no more than an analogy. Synchronized clocks are a physically feasible possibility in every realistic distributed system I’ve seen. The difficulties are merely of a technical nature.

The effects of relativity are non-negligible in GPS, which is essentially nothing but a distributed system on synchronized clocks.

Sure, you can get sufficiently close, and at what cost in terms of developer effort and physical infrastructure? Not everyone is Google, and in most cases if you explicitly have code that doesn't assume synchronicity you will avoid footguns that inexperienced devs will make.

That's exactly the point - there's no such thing as "absolute global time".

Sure there is: its the monotomically increasing count of Planck time "instants" starting from the big bang during which the worlds quantum state ticks forwards.

And which observer is counting those ticks?

We can pick a reference time and place such as Unix time on Earth and relative to that frame of reference, the world is immutable.

At the largest (cosmological) scale, given a metric such as FLRW, you can define a global family of comoving observers, with a corresponding notion of global time: https://en.wikipedia.org/wiki/Cosmic_time. This is less applicable at smaller scales, of course, where other solutions of GR (e.g. the Schwarzschild solution) more accurately model the system under study.

By that not so very useful definition, mutable systems are immutable, since they're in the same state at any specific moment.

> 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.

That has nothing to do with physical reality - it's only about feature set of human-designed systems.

"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.

This video talks about good programming practice regarding immutability and the mutable world:

https://www.destroyallsoftware.com/talks/boundaries

provocative blanket statements like "the real world is immutable" (or otherwise) aren't correct, nor healthy.

Some problems are more easily dealt with using tools like immutability, or mutation for that matter.

as with all things in software - it depends.

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.

Couple of techniques;

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.

Interesting enough several quantum interpretations assume an immutable reality

I've written a lot of software. Using both mutable patterns and immutable patterns.

I keep coming back to the immutable MODEL of things because it mostly works and it is easier to get right and maintain.

I think the author misses the point of MODELLING your systems as immutable

A philosopher would say 'we don't know yet'.

In the world we live in, based on the human accomplishments so far in history, we can say the world i immutable. But over time, we can't be certain.

Reply on news.ycombinator.com