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

411–420 of 663 posts

Re: John Carmack on mutable variables

#411

Post by maleldil »

TZubiri wrote: post #174
sgarland wrote: post #168

Dumb question from a primarily Python programmer who mostly writes (sometimes lengthy) scripts: if you have a function doing multiple API calls - say, to different AWS endpoints with boto3 - would you be expected to have a different variable for each response? Or do you delete the variable after it’s handled, so the next one is “new?”

I think renaming an old variable is a common and sensible way to free a resource in python. If there are no valid names for a resource it will be garbage collected. Which is different in languages like C++ with manual memory management. John Carmack is a C++ programmer apparently that still has a lot to learn in python.

Not "a resource", but memory specifically. If there's a proper resource (e.g. a file), you should ensure it's explicitly released instead of relying on the GC (using with/close/etc.) And if memory usage is really important, you should probably explicitly delete the variable.

Anything else is wishful thinking, trying to rely on the GC for deterministic behaviour.

Re: John Carmack on mutable variables

#412

Post by [deleted] »

everforward wrote: post #315
a4isms wrote: post #223

Earlier quoted context omitted.

In languages like JavaScript, immutable and constant may be theoretically the same thing, but in practice "const" means a variable cannot be reassigned, while "immutable" means a value cannot be mutated in place. They are very, very different semantically, because const is always local. Declaring something const has no effect on what happens with the value bound to a const variable anywhere else in the program. Where…

Arrays are a very notable example here. You can append to a const array in JS and TS, even in the same scope it was declared const. That’s always felt very odd to me.

[deleted]

Re: John Carmack on mutable variables

#413

Post by maleldil »

JonChesterfield wrote: post #198
MrNet32823 wrote: post #153

Jonathan Blow had strong objection with const keyword. I forgot because i did not understand at that time. Does anyone with jai experience have a counter point to that.

I believe the standard counterargument goes: - either it's transitive, in which case your type system is very much more complicated - or it isn't, in which case it's a near useless liability Naturally C++ runs with the latter, with bonus extra typing for all the overloads it induces.

How isn't it transitive in C++? If the variable/reference is const, you can't modify fields, and you can only call const methods. What else do you need?

Re: John Carmack on mutable variables

#414

Post by LogicHound »

1718627440 wrote: post #365
LogicHound wrote: post #144

Earlier quoted context omitted.

There is a huge amount of syntactic sugar that has been added over the years that doesn't do whole lot IMO. It is often imported from other languages (usually JavaScript and/or Python). e.g. Just a very simple example to illustrate the point if (customer != null) { customer.Order = GetCurrentOrder(); } vs if (customer is not null) { customer.Order = GetCurrentOrder(); } Is there really any benefit in adding "is/is no…

In Python '==' and 'is' are not the same thing. '==' checks for equality, 'is' for identity.

I am aware. I probably should have said "inspired".

Re: John Carmack on mutable variables

#415

Post by maleldil »

stevage wrote: post #235
latexr wrote: post #215

Earlier quoted context omitted.

JavaScript’s `const` has the bigger issue that while things can’t be reassigned, they can still mutate. For example: const myArray = [1,2,3] myArray.push(4) myArray // [1, 2, 3, 4]

In what way is that an issue?

Because this isn't immutability. The goal is to have a way to define an object that will never change after initialisation, and JS's const isn't it.

Re: John Carmack on mutable variables

#416

Post by ryandv »

adrianN wrote: post #407
ryandv wrote: post #332

Earlier quoted context omitted.

That's right - immutability enables equational reasoning, where it becomes possible to actually reason through a program just by inspection and evaluation in one's head, since the only context one needs to load is contained within the function itself - not the entire trace, where anything along the thread of execution could factor into your function's output, since anybody can just mutate anybody else's memory willy-…

In theory it’s certainly right that imperative programs are harder to reason about. In practice programmers tend to avoid writing the kind of program where anything can happen.

> In practice programmers tend to avoid writing the kind of program where anything can happen.

My faith in this presumption dwindles every year. I expect AI to only exacerbate the problem.

Since we are on the topic of Carmack, "everything that is syntactically legal that the compiler will accept will eventually wind up in your codebase." [0]

[0] https://www.youtube.com/watch?v=1PhArSujR_A&t=15m54s

Re: John Carmack on mutable variables

#417

Post by jimbokun »

nvader wrote: post #354
slifin wrote: post #96

Yeah I wish variables were immutable by default and everything was an expression Oh well continues day job as a Clojure programmer that is actively threatened by an obnoxious python take over

You are not a Clojure programmer. You use Clojure to solve problems in a professional context. I'm sorry that there's a political tribal war based on language going on at your workplace. But especially now that coding agents are radically enabling gains in developer productivity, you don't need to feel excluded by the artificial tribal boundaries. If you haven't, I recommend reading: https://www.kalzumeus.com/2011/10…

You know I read this when it came out but have gotten out of the habit of applying it.

Thanks for the reminder. Will work on putting these ideas back into practice again.

Re: John Carmack on mutable variables

#419

Post by maleldil »

mr_mitm wrote: post #108

Is there a ruff rule for this?

There are [1] and [2] for function arguments and loop variables, respectively, but nothing for the general case. Note that a type checker will complain if you re-assign with a different type. Pylint also has [3] for redefining variables from an outer scope, but Ruff doesn't implement that yet.

[1] https://docs.astral.sh/ruff/rules/redefined-argument-from-lo...

[2] https://docs.astral.sh/ruff/rules/redefined-loop-name/

[3] https://pylint.pycqa.org/en/latest/user_guide/messages/warni...

Post reply on HN