
The real world is mutable – consequences for system design - ash
https://utcc.utoronto.ca/~cks/space/blog/tech/RealWorldIsMutable
======
TeMPOraL
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.

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

~~~
TeMPOraL
> _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.

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

~~~
dathinab
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).

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

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

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

------
dustingetz
Or is it, because physics!

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

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

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

~~~
bollu
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)).

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

~~~
k__
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?

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

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

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

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

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

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

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

[https://www.destroyallsoftware.com/talks/boundaries](https://www.destroyallsoftware.com/talks/boundaries)

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

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

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

------
diminish
Interesting enough several quantum interpretations assume an immutable reality

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

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

