Live data from Hacker News

John Carmack on mutable variables

twitter.com

501–510 of 663 posts

Re: John Carmack on mutable variables

#501
post #341

Earlier quoted context omitted.

I guess I'm not that good a programmer, because I don't really understand why variables that can't be varied are useful, or why you'd use that. How do you write code that actually works?

If you need new values you just make new things. If you want to do an operation on fooA, you don't mutate fooA. You call fooB = MyFunc(fooA) and use fooB. The nice thing here is you can pass around pointers to fooA and never worry that anything is going to change it underneath you. You don't need to protect private variables because your internal workings cannot be mutated. Other code can copy it but not disrupt it.

> If you want to do an operation on fooA, you don't mutate fooA. You call fooB = MyFunc(fooA) and use fooB.

This is the bit I don't get.

Why would I do that? I will never want a fooA and a fooB. I can't see any circumstances where having a correct fooB and an incorrect fooA kicking around would be useful.

Re: John Carmack on mutable variables

#502

I completely agree with the assertion and the benefits that ensue, but my attention is always snagged by the nomenclature. I know there are alternate names available to us, but even in the context of this very conversation (and headline), the thing is being called a "variable." What is a "variable" if not something that varies?

Some languages like Kotlin have var and val introducing the distinction between variables (that are expected to get reassigned, to vary over time, and values, which are just that, a value that has been given a name. I like these small improvements.

(unfortunately, Kotlin then goes on and introduces "val get()" in interfaces, overloading the val term with the semantics of "read only, but may very well change between reads, perhaps you could even change it yourself through some channel other than simple assignment which is a definite no")

Re: John Carmack on mutable variables

#503

Earlier quoted context omitted.

Okay, so for example I might set something like "this bunch of parameters" immutable, but "this 16kB or so of floats" are just ordinary variables which change all the time? Or then would the block of floats be "immutable but not from this bit"? So the code that processes a block of samples can write to it, the code that fills the sample buffer can write to it, but nothing else should?

Sounds like you have a data structure like `Array `. The immutable approach has methods on Array like: Array append(Float value); Array replace(int index, Float value); The methods don't mutate the array, they return a new array with the change. The trick is: How do you make this fast without copying a whole array? Clojure includes a variety of collection classes that "magically" make these operations fast, for a var…

> The methods don't mutate the array, they return a new array with the change.

But then I need to update a bunch of stuff to point to the new array, and I've still got the old incorrect array hanging around taking up space.

This just sounds like a great way to introduce bugs.

Re: John Carmack on mutable variables

#504

After a 2 year Clojure stint I find it very hard to explain the clarity that comes with immutability for programmers used to trigger effects with a mutation. I think it may be one of those things you have to see in order to understand.

I would say it's more than immutability - it's the "feel" of working with values. I've worked with at least 6 languages professionally and likely more for personal projects over last 20 years. I can say that Clojure was the most impactful language I learned. I tried to learn Haskel before but I just got bogged down in the type system and formalization - that never sat with me (ironically in retrospect Monads are a tr…

I have dreams of being at a “Clojure shop” but I fear daily professional use might dull my love for the language. Having to realize that not everyone on my team wants to learn lisp (or FP) just to work with my code (something I find amazing and would love to be paid to do) was hard.

On a positive note I have taken those lessons from clojure (using values, just use maps, Rich’s simplicity, functional programming without excessive type system abstraction, etc) and applied them to the rest of my programming when I can and I think it makes my code much better.

Re: John Carmack on mutable variables

#505

Earlier quoted context omitted.

I guess I'm not that good a programmer, because I don't really understand why variables that can't be varied are useful, or why you'd use that. How do you write code that actually works?

The concept is actually pretty simple: instead of changing existing values, you create new values. The classic example is a list or array. You don't add a value to an existing list. You create a new list which consists of the old list plus the new value. [1] This is a subtle but important difference. It means any part of your program with a reference to the original list will not have it change unexpectedly. This eli…

> It means any part of your program with a reference to the original list will not have it change unexpectedly.

I don't get why that would be useful. The old array of floats is incorrect. Nothing should be using it.

That's the bit I don't really understand. If I have a list and I do something to it that gives me another updated list, why would I ever want anything to have the old incorrect list?

Re: John Carmack on mutable variables

#506

I completely agree with the assertion and the benefits that ensue, but my attention is always snagged by the nomenclature. I know there are alternate names available to us, but even in the context of this very conversation (and headline), the thing is being called a "variable." What is a "variable" if not something that varies?

You could always interpret a variable from the perspective of it's memory address. It is clearly variable in the sense that it can and will change between allocations of that address, however an immutable variable is intended to remain constant as long as the current allocation of it remains.

Re: John Carmack on mutable variables

#507
post #277

Earlier quoted context omitted.

I would be nicer if you gave x1 and x2 meaningful names

What would those names be in this example?

In a real application meaningful names are nearly always possible, eg:

    const pi = 3.1415926
    const 2pi = 2 * pi
    const circumference = 2pi * radius

Re: John Carmack on mutable variables

#508
post #150
post #115

Variable is by definition mutable. Constant is by definition immutable. Why can't people get it through their heads in 2025? (I'm looking at you, Rust)

A constant is a variable that _always_ has the same value on all lifecycles, e.g. const int a{10}; An immutable variable well ... does not void some_function(const int a); Can you tell me what is the value of `a` on both cases?

I’m not sure why witx’s comment was downvoted. This is absolutely the standard usage in math and computer science.

Re: John Carmack on mutable variables

#509

I completely agree with the assertion and the benefits that ensue, but my attention is always snagged by the nomenclature. I know there are alternate names available to us, but even in the context of this very conversation (and headline), the thing is being called a "variable." What is a "variable" if not something that varies?

Variables are called variables because their values can vary between one execution of the code and the next. This is no different for immutable variables. A non-variable, aka a constant, would be something that has the same value in all executions.

Example:

  function circumference(radius)
      return 2 * PI * radius
Here PI is a constant, while radius is a variable. This is independent of whether radius is immutable or not.

It doesn’t have to be a function parameter. If you read external input into a variable, or assign to it the result of calling a non-pure function, or of calling even a pure function but passing non-constant expressions as arguments to it, then the resulting value will in general also vary between executions of that code.

Note how the term “variable” is used for placeholders in mathematical formulas, despite no mutability going on there. Computer science adopted that term from math.

https://en.wikipedia.org/wiki/Variable_(mathematics)

Re: John Carmack on mutable variables

#510

Earlier quoted context omitted.

Sounds like you have a data structure like `Array `. The immutable approach has methods on Array like: Array append(Float value); Array replace(int index, Float value); The methods don't mutate the array, they return a new array with the change. The trick is: How do you make this fast without copying a whole array? Clojure includes a variety of collection classes that "magically" make these operations fast, for a var…

> The methods don't mutate the array, they return a new array with the change. But then I need to update a bunch of stuff to point to the new array, and I've still got the old incorrect array hanging around taking up space. This just sounds like a great way to introduce bugs.

It ends up being quite the opposite - many, many bugs come from unexpected side effects of mutation. You pass that array to a function and it turns out 10 layers deeper in the call stack, in code written by somebody else, some function decided to mutate the array.

Immutability gives you solid contracts. A function takes X as input and returns Y as output. This is predictable, testable, and thread safe by default.

If you have a bunch of stuff pointing at an object and all that stuff needs to change when the inner object changes, then you "raise up" the immutability to a higher level.

    Universe nextStateOfTheUniverse = oldUniverse.modifyItSomehow();
If you keep going with this philosophy you end up with something roughly like "software transactional memory" where the state of the world changes at each step, and you can go back and look at old states of the world if you want.

Old states don't hang around if you don't keep references to them. They get garbage collected.

Post reply on HN