I've said before that immutable data is easier to reason about because it's more like the real world. That seems counterintuitive because the world...
For further actions, you may consider blocking this person and/or reporting abuse
i was digging the nice prosemirror module, which implements immutability at the core of an html wysiwyg editor. That module uses two core immutability concepts:
When using it and reading the docs, i was struck by how these two concepts are perfectly implemented as:
The analogy seems to be so deep i didn't yet found the bottom of it.
Even the way we describe the universe uses the concept of immutability :)
I'm not sure if I know enough about the physics you're talking about. I do remember that Haskell's source control system used quantum entanglement math to model the interaction of patches.
Precisely: it follows (well, almost) directly from the non-commutativity of the interaction particles (which propagate state change). It's crazy shit !
Even filling a cabinet could be a function that takes a cabinet and returns a new cabinet, but point taken;)
When we talk about something shared, we also identify something and refer to it. Mutability would mean that we change something without changing it's identity. And immutability would mean that we also change the identity. But how in the real world we know that something is the same or changed? Tastes like chicken - gotta be chicken;) I think in real world, when we expect change we use containers. We give it an identity and expect contents to change, but not the containers itself. That looks like an object with data inside;) But wait a minute! Object is intended to be an instance of a class. It's like having a blueprint (class) and several things (object) built from this blueprint. That looks like we are manufacturing containers to store something, but is this what we are intended to have in the first place? We might have wanted something unique with identity to store our changing data. I think the problem is that data should stay data, and not be a part of an object. I've seen Java objects becoming so big that they look more like a separate subprogram with it's own data and functions. Now imagine this class has a superclass and a child class. How crooked is that?;) One program become a parent of another program, which itself can have children. That escalated quickly.
I gather it would be more reasonable to separate namespaces from classes like Clojure does. Who in sane mind would want to put data in a namespace? That makes no sense, so that data in objects be;)
After clojure.spec it became clear to me how we really reason about data. We state our expectations. It's more verbose than types, but what is type? It's name that is attached to data. Name doesn't tell much, huh? In this respect spec tells more about the data then a type. It's a less strict contract that is closer to what we have in real life and that's amazing.
Rock on! I'm glad you get what I'm talking about.
Great analogy. In fact, one strategy I've heard when modeling a tricky business process is asking the question "How would we do this if we were using papers instead of computers?".
Yes! I love this question!