Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

John Carmack on mutable variables

twitter.com

Post reply on HN
Print view View original

341–350 of 663 posts

Re: John Carmack on mutable variables

#341

Post by jayd16 »

ErroneousBosh wrote: post #250
EastLondonCoder wrote: post #128

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?

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.

Re: John Carmack on mutable variables

#342

Post by marginalia_nu »

Const-me wrote: post #236

For performance critical code, you want to reuse L1D cache lines as much as possible. In many cases, allocation of a new immutable object boils down to malloc(). Newly allocated memory is unlikely to be found on L1D cache. OTOH, replacing data in recently accessed memory and reusing the memory is very likely to become L1D cache hit in runtime.

For performance critical code, you wouldn't use malloc()-allocation at all, though whether using an arena allocator or putting stuff on the stack, your argument is still sane. Data locality is speed.

Re: John Carmack on mutable variables

#343

Post by jayd16 »

anymouse123456 wrote: post #283

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?

A common naming is value. You can call them immutable values and mutable variables.

Another way to look at it is a variables are separate from compile time constants whether you mutate them or not.

Re: John Carmack on mutable variables

#344

Post by catlifeonmars »

TheRoque wrote: post #306

I also default to const in javascript. Somehow a "let" variable feels so dirty, but I don't really know why. I guess at this point my experience forged an instinct but I can't even put a theory on it. But it's sometimes necessary and I use it of course.

In JS, by using const, you are signalling to the reader that they don’t need to look out for a reassignment to understand the code. If you use let, you are saying the opposite.

Re: John Carmack on mutable variables

#347

Post by AnotherGoodName »

villgax wrote: post #165
lopatin wrote: post #12

How fast this got to the top, you would think John Carmack just invented nuclear fusion.

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.

Re: John Carmack on mutable variables

#348

Post by catlifeonmars »

AstroBen wrote: post #329
hn_throw2025 wrote: post #249

Earlier quoted context omitted.

In the context of the original discussion, TypeScript (and ES6) has const and let.

well yeah except const doesn't make objects or arrays immutable

I feel that Java’s “final” would have been a better choice than “const”. It doesn’t have the same confusing connotation.

Re: John Carmack on mutable variables

#349

Post by leviathan »

acdbddh wrote: post #299

In python its common to see code like this: df = pd.concat(df,other_df) df = df.select(...) ... My eyes hurts, when I see it. It makes me avoid python. I bet the reason for this mutable code is a missing simple pipes syntax. I love pipes. In R can do: df |> rbind(other_df) |> select(...) It feels much better.

My eyes would hurt more if I had to look all day at the vertical misalignment of that |> operator

Re: John Carmack on mutable variables

#350

Post by AaronAPU »

furyofantares wrote: post #301
AaronAPU wrote: post #267

This would require coming up with an order of magnitude more variable names which is just unnecessary cognitive load.

An order of magnitude? That sounds like pretty outrageous hyperbole. A variable getting reassigned 10 times sounds extremely rare, the average in my experience has to be less than 1 reassignment. I think the approach requires coming up with maybe 10% more names. Usually there are good, obvious names for intermediate calculations in my experience. I'm open though - what kinds of things are you doing that require reass…

Probably exaggerated a bit with that phrasing (“outrageous” seems similarly hyperbolic ;))

But any variable which I’ve not already marked as const is pretty much by definition going to be modified at least once. So now instead of 1 variable name you need at least two.

So now the average number of variables per non-const variable is >= 2 and will be much more if you’re doing for example DSP related code or other math heavy code.

You can avoid it with long expressions but that in principle is going against the “name every permutation” intention anyway.

Post reply on HN