Live data from Hacker News

John Carmack on mutable variables

twitter.com

631–640 of 663 posts

Re: John Carmack on mutable variables

#631

Earlier quoted context omitted.

> In Rust we'd use `const` for this but in C you need to use the C pre-processor language instead to make constants, which is kinda wild. I get that you're not very familiar with C? Because in C we'd use const as well. const int x = 2; x = 3; // error: assignment of read-only variable 'x'

That's not a constant, that's an immutable variable which is why your diagnostic said it was read-only. const int x = 2; int *p = &x; *p = 3; // Now x is 3 And since I paid for the place where I'm writing this with cash earned writing C a decade or so ago, I think we can rule out "unfamiliar with C" as a symptom.

Now x is 3 but you also get a compiler warning telling you not to do that.

In my opinion it's a bit disingenuous to argue that it isn't a const just because you can ignore the compiler and shoot yourself in the foot. If you listen to the compiler, it is reflected in the assembly that it is a constant value the same as #define x 2.

Is Rust better at enforcing guarantees? Of course. Is `const` in C `const` if you don't ignore compiler warnings and errors? Also of course.

> And since I paid for the place where I'm writing this with cash earned writing C a decade or so ago

Ditto!

Re: John Carmack on mutable variables

#632

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

[deleted]

Re: John Carmack on mutable variables

#634

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…

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

Getting back to this, though - where would this be useful? What would do this?

I'm not getting why having a new list that's different from the old list, with some code working off the old list and some working off the new list, is anything you'd ever want.

Can you give a practical example of something that uses this?

Why doesn't the list just have a mutex?

Re: John Carmack on mutable variables

#635

Earlier quoted context omitted.

But that's just it, why would a copy ever happen? Why would you want a correct and an incorrect version of your variable hanging about?

Taking your point of view: you assigned a value1 to a name. Then you assigned a value2 to the same name. You say that value2 is correct. It logically follows that value1 was incorrect . Why did you assign it then? The names are free, you can just use a correct name every single time.

Because the account owner withdrew money . The player scored a goal, the month ticked over, the rain started, the car accelerated, a new comment was added to the thread .

The world by definition mutates over time.

Re: John Carmack on mutable variables

#636

Earlier quoted context omitted.

Taking your point of view: you assigned a value1 to a name. Then you assigned a value2 to the same name. You say that value2 is correct. It logically follows that value1 was incorrect . Why did you assign it then? The names are free, you can just use a correct name every single time.

Because the account owner withdrew money . The player scored a goal, the month ticked over, the rain started, the car accelerated, a new comment was added to the thread . The world by definition mutates over time.

Ah, true. If the var is a part of a long-living state, all good. That's just rarely seen in CRUD apps, more common in games.

Re: John Carmack on mutable variables

#637

Earlier quoted context omitted.

Just like AGI he was supposedly brought on board for but…..checks notes. Nothing.

>Just like AGI he was supposedly brought on board for but…..checks notes. Nothing. His AGI work was entirely his own? As in he literally stepped down from a high level corporate role where he was responsible for Oculus (3D games/applications) to do this in his own time. Similar to his work on Armadillo Aerospace.

Oculus wich also failed hard.

Re: John Carmack on mutable variables

#638
post #32

Earlier quoted context omitted.

Which one, Erlang, Lisp, or ML?

Honestly I find ML derived languages the most pleasant to look at.

I prefer Piet, but it has some real drawbacks when it comes to readability: https://www.dangermouse.net/esoteric/piet/samples.html

Re: John Carmack on mutable variables

#639

Earlier quoted context omitted.

Can you clarify?

Modern CPUs do out-of-order execution, which means they need to identify and resolve register sharing dependencies between instructions. This turns the notional linear model of random-access registers into a DAG in practice, where different instructions that might be in flight at once actually read from or write to different "versions" of a named register. Additionally, pretty much every modern CPU uses a register re…

That doesn't affect what I said though. Register renaming and pipelining does not make mutation go away and doesn't allow you to work on multiple things "at once" through the same pointer.

It's still logically the same thing with these optimizations, obviously -- since they aren't supposed to change the logic.

Re: John Carmack on mutable variables

#640
The efficiency advantage of immutability needs to be made more transparent and understood by engineers. Memory flexibility and recyclability have potential costs and should be minimized as much as possible. More importantly, mutability is often unnecessary.
Post reply on HN