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

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

Not that in mutable languages == can either mean storage equality or value equality. In immutable languages there is only value equality.

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.

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

> 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

Edit: I should clarify that I mean "immutable" in the context of primitive values like integers.

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.

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

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

Ncurses example (full text-editor): https://github.com/arximboldi/ewig

SDL example: https://twitter.com/sinusoidalen/status/939539173584916480

Immutable data: https://github.com/arximboldi/immer

(There was a talk about Lager at MeetingCpp this year, still waiting for it to be published online...)

Thank you Juan for the talks (I watched both the CppNow, and CppCon, though the latter one is even better). Also for the wonderful libs, and the real-life example (your text editor).

At work, we are pondering on a new way to split our game levels editing code, and persistent data structures came to me as one idea, in order to handle UNDO in generic way, and they by diff, or other means visualize the changes. I've read Okasaki's book long time ago, but seeing this implemented in a imperative language is really helpful.

Also pretty much enjoyed the post-modern talk too :) - hehehe

Thank you!

Thanks a lot Malkia, that is super encouraging!

Editing code for game levels seems to me like a quite good use-case for this. "Editing" software with rich hierarchical documents is the itch I originally wanted to scratch with this work, even though there are many other use-cases too. Feel free to send me an email if you move further with that idea or if you want to discuss any of these topics with me :-)

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

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

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.

Hi arximboldi!

I actually have a half-started emacs-like editor built using Qt that is based on ewig. Not anywhere near usable yet, but my plan is to make a fast editor with fast highlighting and such, and have everything accessible to be scripted in guile. I doubt it will actually materialise, but if I ever get a proof of concept it will be on github.

I love immer! It is friggin excellent.

Hey that's awesome! Let me know if you ever would like me to take a look at your code or anything. I'd be happy to link it from the Immer site too when you are ready to promote it :-)

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

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.