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

641–650 of 663 posts

Re: John Carmack on mutable variables

#641

Post by a4isms »

everforward wrote: post #627
a4isms wrote: post #603

Earlier quoted context omitted.

There is no exception for ANY data structure that includes references to other data structures or primitives. Not only can you add or remove elements from an array, you can change them in place. A const variable that refers to an array is a const variable. The array is still mutable. That's not an exception, its also how a plain-old JavaScript object works: You can add and remove properties at will. You can change it…

I know, and I do agree it's consistent, but then it doesn't make any sense to me as a keyword in a language where non-primitives are always by-reference. You can't mutate the reference, but you _can_ copy the values from one array into the data under an immutable reference, so const doesn't prevent basically any of the things you'd want to prevent. The distinction makes way more sense to me in languages that let you…

The beauty of `const` in JS is that it's almost completely irrelevant. Not only does it have nothing to do with immutability, it's also local. Which means, if I were to write `let` instead of `const`, I could still see whether my code reassigned that variable at a glance. The keyword provides very little in the way of a guarantee I could not otherwise observe for myself.

Immutability is completely different. Determining whether a data structure is mutated without an actual immutable type to enforce is impractical, error-prone, and in any event impossible to prove for the general case.

Re: John Carmack on mutable variables

#642

Post by cookiengineer »

fuzzythinker wrote: post #78
cookiengineer wrote: post #62

Earlier quoted context omitted.

Technically you could just use an assignment ternary expression for this: const y = (x === true) ? true : false; I used this kind of style for argument initialization when I was writing JS code, right at the top of my function bodies, due to ES not being able to specify real nullable default values. (and I'm setting apart why I think undefined as a value is pointless legacy). Composite.prototype.SetPosition(x, y, z)…

nitpick: cleaner w/o ()'s, as '=' is the 2nd lowest operator, after the comma separation operator.

I guess I'm that one guy that likes expression brackets and statement ending symbols.

Re: John Carmack on mutable variables

#643

Post by rao-v »

LogicHound wrote: post #209
mrsmrtss wrote: post #181

Earlier quoted context omitted.

In your sample there really is no benefit to using the "is" operator over just checking for null (assuming you haven't overloaded the "!=" operator). However, the "is" operator is a lot more powerful, you can match an expression against a pattern with it. Would you say that these samples show no benefit to using the "is" operator? if (obj is string s) { ... } if (date is { Month: 10, Day: https://learn.microsoft.com/…

The issue is that I dislike the overall mentality of just adding a bunch of language features. Things just seem to be dumped in each release and I think to myself "When I am going to use that?". > Would you say that these samples show no benefit to using the "is" operator? I didn't say no benefit . I said dubious benefit . I didn't really want to get into discussing specific operators, but lets just use your date exa…

I have to admit this really does seem like beautiful syntactic sugar despite me not being a fan of accumulating keywords in languages. Your example of writing a function instead of a neat little lambda is clunkier to quickly scan for correctness.

Re: John Carmack on mutable variables

#644

Post by DrScientist »

MetaWhirledPeas wrote: post #472
DrScientist wrote: post #462

Earlier quoted context omitted.

I think you missed the point. I understand that if you writing a simple function with an expected interface/behaviour then that's all you need to understand. Note this isn't something unique to a functional approach. However, somebody needs to know how the entire program works - so my question was where does that application state live in a purely functional world of immumutables? Does it disappear into the call stac…

It didn't disappear; there's just less of it. Only the stateful things need to remain stateful. Everything else becomes single-use. Declaring something as a constant gives you license to only need to understand it once . You don't have to trace through the rest of the code finding out new ways it was reassigned. This frees up your mind to move on to the next thing.

And what about that state that needs to exist? - like application state ( for example this text box has state in terms of keeping track of text entered, cursor position etc ).

Where does that go?

Are you creating a new immutable object at every keystroke that represents the addition of the latest event to the current state?

Even then you need to store a pointer to that current state somewhere right?

Re: John Carmack on mutable variables

#645

Post by acdbddh »

related quote from Carmack:

> "A large fraction of the flaws in software development are due to programmers not fully understanding all the possible states their code may execute in."

https://web.archive.org/web/20201229045320/https://www.gamas...

And variable mutations increase the cognitive load necessary to understand all the possible states.

Re: John Carmack on mutable variables

#646

Post by DrScientist »

jimbokun wrote: post #526
DrScientist wrote: post #468

Earlier quoted context omitted.

> Once you identify the part of the program that needs to change, And how do you do that without understanding how the program works at a high level? I understand the value of clean interfaces and encapsulation - that's not unique to functional approaches - I'm just wondering in the world of pure immutability where the application state goes. What happens if the change you need to make is at a level higher than a sin…

Yes, obviously a program with no mutability only heats up the CPU. The point is to determine the points in your program where mutation happens, and the rest is immutable data and pure functions. In the case of interacting services, for example, mutation should happen in some kind of persistent store like a database. Think of POST and PUT vs GET calls. Then a higher level service can orchestrate the component services…

> The point is to think carefully about where to place mutability into your architecture and not arbitrarily scatter it everywhere.

So you mean like having a centralised stateful application model for example?

Re: John Carmack on mutable variables

#647

Post by throwaway2037 »

munificent wrote: post #439
skeezyjefferson wrote: post #205

Earlier quoted context omitted.

whats the difference between immutable and constant, which has been in use far longer? why are you calling it mutable?

"Constant" is ambiguous. Depending on who you ask, it can mean either: 1. A property known at compile time. 2. A property that can't change after being initially computed. Many of the benefits of immutability accrue properties whose values are only known at runtime but which are still known to not change after that point.

DotNet/C# makes this distinction in the form of (1) const and (2) readonly.

Re: John Carmack on mutable variables

#648

Post by throwaway2037 »

filoeleven wrote: post #612
MetaWhirledPeas wrote: post #475

Earlier quoted context omitted.

> it'd require too much discipline to do such a thing in Python Is Python that different from JavaScript? Because it's easy in JavaScript. Just stop typing var and let, and start typing const. When that causes a problem, figure out how to deal with it. If all else fails: "Dear AI, how can I do this thing while continuing to use const? I can't figure it out."

Javascript only enforces reassignments to const. So this, const arr = [] arr.push(“grape nuts”] is just peachy in JS and requires the programmer to avoid using it. More importantly, because working immutably in JS is not enforced, trying to use it consistently either limits which libraries you can use and/or requires you to wrap them to isolate their side effects. ImmerJS can help a lot here, since immutability is it…

    > Javascript only enforces reassignments to const.
Java is the same with the keyword final. I never heard anyone complain about it. Are you asking for the special hell that is C++ const correctness?

Re: John Carmack on mutable variables

#649

Post by SAI_Peregrinus »

MetaWhirledPeas wrote: post #475
ndr wrote: post #237

Earlier quoted context omitted.

Clojure also makes it very easy, it'd require too much discipline to do such a thing in Python. Even Carmack, who I think still does python mostly by himself instead of a team, is having issues there.

> it'd require too much discipline to do such a thing in Python Is Python that different from JavaScript? Because it's easy in JavaScript. Just stop typing var and let, and start typing const. When that causes a problem, figure out how to deal with it. If all else fails: "Dear AI, how can I do this thing while continuing to use const? I can't figure it out."

Python doesn't have constants at the language level. You can create classes without setter properties, only getter properties, to have constant objects. This is rare, usually people just write the name in SCREAMING_SNAKE_CASE to document it's supposed to be a constant but Python will still allow mutating it.

Re: John Carmack on mutable variables

#650

Post by 1-more »

garethrowlands wrote: post #297
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?

The term 'variable' is from mathematics. As others have said, the values of variables do vary but they do not mutate.

They are often called bindings, not variables, so as to make it clear that they are just a name for a thing that will not change.
Post reply on HN