4 ms·

I sometimes like to explain things the other way around. Immutability being version control for program state. I rarely use functional programming but I certai

I sometimes like to explain things the other way around. Immutability being version control for program state. I rarely use functional programming but I certainly see its appeal for certain things. I think the concept of immutability confuses people. It really clicked for me when I stopped thinking of it in terms of things not being able to change and started instead to think of it in terms of each version of things having different names, somewhat like commits in version control. Functional programming makes explicit, not only which variables you are accessing, but which version of it. It may seem like you are copying variables every time you want to modify them but really you are just giving different mutations, different names. This doesn't mean things are actually copied in memory. The compiler doesn't need to keep every versions. If it sees that you are not going to reference a particular mutation, it might just physically overwrite it with the next mutation. In the background "var a=i, var b=a+j", might compile as something like "var b = i; b+=j";

macintux 9y ago
That's an interesting way to describe it. I've talked a lot about immutability at conferences, but I've never thought about it in those terms. Thanks.
- masklinn 9y ago
  That realisation has been used by environments like Elm's Reactor[0] or its (sadly defunct) Time Traveling debugger. I think Om also had something like that. Basically, if you use persistent data structures and a unified application state, you can keep a list of all previous application states and you can browse it or ship it for debugging, it's not that expensive. [0] in debug mode, you get a list of all events having occurred in your application and can instantly move back to that state, and you can import/export that state history: http://elm-lang.org/blog/the-perfect-bug-report http://elm-lang.org/blog/the-perfect-bug-report
  - arximboldi 9y ago
    I am working on something like that for C++, a library + debugger called Lager. Quite experimental yet, but been using it to write apps with SDL and Ncurses and I am happy with how it is going... In the end it is a very simple architecture, implementable in any language. Good immutable data-structures are important for big programs though. Library: https://github.com/arximboldi/lager https://github.com/arximboldi/lager Ncurses example (full text-editor): https://github.com/arximboldi/ewig https://github.com/arximboldi/ewig SDL example: https://twitter.com/sinusoidalen/status/939539173584916480 https://twitter.com/sinusoidalen/status/939539173584916480 Immutable data: https://github.com/arximboldi/immer https://github.com/arximboldi/immer (There was a talk about Lager at MeetingCpp this year, still waiting for it to be published online...)
    - masklinn 9y ago
      > Good immutable data-structures are important for big programs though. I'm guessing you mean good in the sense of well-implemented (performant), but I think good in terms of interface is also very important For instance in my experience & opinion Immutable.JS is not very fun to use regardless of its implementation, because the interface does not feel natural for the language (not that the designers can really be faulted, the user-accessible part of the language simply limits what they can do). I think a similar library for Python would have similar issues (due to Python being very statements-oriented which is antithetical to persistent data structures).
      - no_wizard 9y ago
        Python however does provide some immutable constructs as part of it’s core language (Tuples) It also has the ability to really take any object and attach states to it at whim, including immutability. I think that’s a better trade off than JS
        masklinn 9y ago
        I think you completely missed my point. That aside, > Python however does provide some immutable constructs as part of it’s core language (Tuples) That doesn't really help when you're looking for persistent datastructures. > It also has the ability to really take any object and attach states to it at whim, including immutability. No, and if it did that would not be an advantage in this context.
runeks 9y ago
> I think the concept of immutability confuses people. I think it confuses people because it’s framed oddly. Immutability isn’t about being unable to mutate state, it’s about no longer using containers (registers) as variables, such that the equal operator actually means “equals” as opposed to “store”. In most programming languages, the equal operator works as a “store” operation, which stores a value in a named container/register. In “immutable by default” languages like Haskell, the equal operator actually means “equals”, as in “is synonymous with”. The essence of immutability is referencing values directly, through synonyms, as opposed to storing them in named registers for later retrieval. When it’s done this way, immutability no longer makes sense: is the number 3 mutable? Can the number 3 be mutated into 4, or are they just two distinct numbers?
- canes123456 9y ago
  I think I understand the point you are making but this is way more confusing for me. Partly this can be blamed on imperative lanuages and = vs ==.
  - sbergot 9y ago
    Not that in mutable languages == can either mean storage equality or value equality. In immutable languages there is only value equality.
  - giesch 9y ago
    In a procedural language: x == 3 means: Take the value out of the box x. Is it 3? x = 3 means: x is a box, put 3 in it. The 3 lasts forever, or until someone changes it. In a functional language: x = 3 means: Take the value out of box x. Is it 3? let x = 3 in [...] means: x is a box, put a 3 in it. The 3 lasts for only the [...], but cannot be undone.
    - nybble41 9y ago
      Correction: In a functional language (specifically Haskell): x = 3 means: x is defined as 3. x == 3 means: Is x equal to 3? let x = 3 in [...] means: within the scope of [...], x is defined as 3. There is no specific point where something is "put into the box" or "taken out of the box". In fact, there is no "box". The functional programming concept of "bindings" does not correspond to the imperative concept of "variables", not even the oxymoron known was "constant variables". (If you want variables in Haskell you need IORef or STRef, where the load and store operations are explicit monadic actions.)
runT1ME 9y ago
Nice, good explanation. And one way to look at the State Monad is when you always want the 'latest version' of an immutable 'value' that keeps getting new versions. :)
sobellian 9y ago
> In the background "var a=i, var b=a+j", might compile as something like "var b = i; b+=j"; Believe it or not, many compilers internally represent mutable variables as a sequence of immutable variables: https://en.wikipedia.org/wiki/Static_single_assignment_form https://en.wikipedia.org/wiki/Static_single_assignment_form Edit: I should clarify that I mean "immutable" in the context of primitive values like integers.
antoaravinth 9y ago
That's good explanation. I guess Immutable.js does uses the same concept behind the scene to retrieve each references i.e like commits. Looks like Immutable.js uses Tries data structures for such operations. May be I'm wrong here as well.

macintux 9y ago

That's an interesting way to describe it. I've talked a lot about immutability at conferences, but I've never thought about it in those terms. Thanks.

masklinn 9y ago
That realisation has been used by environments like Elm's Reactor[0] or its (sadly defunct) Time Traveling debugger. I think Om also had something like that. Basically, if you use persistent data structures and a unified application state, you can keep a list of all previous application states and you can browse it or ship it for debugging, it's not that expensive. [0] in debug mode, you get a list of all events having occurred in your application and can instantly move back to that state, and you can import/export that state history: http://elm-lang.org/blog/the-perfect-bug-report http://elm-lang.org/blog/the-perfect-bug-report
- arximboldi 9y ago
  I am working on something like that for C++, a library + debugger called Lager. Quite experimental yet, but been using it to write apps with SDL and Ncurses and I am happy with how it is going... In the end it is a very simple architecture, implementable in any language. Good immutable data-structures are important for big programs though. Library: https://github.com/arximboldi/lager https://github.com/arximboldi/lager Ncurses example (full text-editor): https://github.com/arximboldi/ewig https://github.com/arximboldi/ewig SDL example: https://twitter.com/sinusoidalen/status/939539173584916480 https://twitter.com/sinusoidalen/status/939539173584916480 Immutable data: https://github.com/arximboldi/immer https://github.com/arximboldi/immer (There was a talk about Lager at MeetingCpp this year, still waiting for it to be published online...)
  - masklinn 9y ago
    > Good immutable data-structures are important for big programs though. I'm guessing you mean good in the sense of well-implemented (performant), but I think good in terms of interface is also very important For instance in my experience & opinion Immutable.JS is not very fun to use regardless of its implementation, because the interface does not feel natural for the language (not that the designers can really be faulted, the user-accessible part of the language simply limits what they can do). I think a similar library for Python would have similar issues (due to Python being very statements-oriented which is antithetical to persistent data structures).
    - no_wizard 9y ago
      Python however does provide some immutable constructs as part of it’s core language (Tuples) It also has the ability to really take any object and attach states to it at whim, including immutability. I think that’s a better trade off than JS
      - masklinn 9y ago
        I think you completely missed my point. That aside, > Python however does provide some immutable constructs as part of it’s core language (Tuples) That doesn't really help when you're looking for persistent datastructures. > It also has the ability to really take any object and attach states to it at whim, including immutability. No, and if it did that would not be an advantage in this context.

runeks 9y ago

> I think the concept of immutability confuses people. I think it confuses people because it’s framed oddly. Immutability isn’t about being unable to mutate state, it’s about no longer using containers (registers) as variables, such that the equal operator actually means “equals” as opposed to “store”. In most programming languages, the equal operator works as a “store” operation, which stores a value in a named container/register. In “immutable by default” languages like Haskell, the equal operator actually means “equals”, as in “is synonymous with”. The essence of immutability is referencing values directly, through synonyms, as opposed to storing them in named registers for later retrieval. When it’s done this way, immutability no longer makes sense: is the number 3 mutable? Can the number 3 be mutated into 4, or are they just two distinct numbers?

canes123456 9y ago
I think I understand the point you are making but this is way more confusing for me. Partly this can be blamed on imperative lanuages and = vs ==.
- sbergot 9y ago
  Not that in mutable languages == can either mean storage equality or value equality. In immutable languages there is only value equality.
- giesch 9y ago
  In a procedural language: x == 3 means: Take the value out of the box x. Is it 3? x = 3 means: x is a box, put 3 in it. The 3 lasts forever, or until someone changes it. In a functional language: x = 3 means: Take the value out of box x. Is it 3? let x = 3 in [...] means: x is a box, put a 3 in it. The 3 lasts for only the [...], but cannot be undone.
  - nybble41 9y ago
    Correction: In a functional language (specifically Haskell): x = 3 means: x is defined as 3. x == 3 means: Is x equal to 3? let x = 3 in [...] means: within the scope of [...], x is defined as 3. There is no specific point where something is "put into the box" or "taken out of the box". In fact, there is no "box". The functional programming concept of "bindings" does not correspond to the imperative concept of "variables", not even the oxymoron known was "constant variables". (If you want variables in Haskell you need IORef or STRef, where the load and store operations are explicit monadic actions.)

runT1ME 9y ago

Nice, good explanation. And one way to look at the State Monad is when you always want the 'latest version' of an immutable 'value' that keeps getting new versions. :)

sobellian 9y ago

> In the background "var a=i, var b=a+j", might compile as something like "var b = i; b+=j"; Believe it or not, many compilers internally represent mutable variables as a sequence of immutable variables: https://en.wikipedia.org/wiki/Static_single_assignment_form https://en.wikipedia.org/wiki/Static_single_assignment_form Edit: I should clarify that I mean "immutable" in the context of primitive values like integers.

antoaravinth 9y ago

That's good explanation. I guess Immutable.js does uses the same concept behind the scene to retrieve each references i.e like commits. Looks like Immutable.js uses Tries data structures for such operations. May be I'm wrong here as well.