Live data from Hacker News

John Carmack on mutable variables

twitter.com

171–180 of 663 posts

Re: John Carmack on mutable variables

#172

I like the idea of immutable-by-default, and in my own musings on this I've imagined a similar thing except that instead of a mutable keyword you'd have something more akin to Python's with blocks, something like: # Immutable by default x = 2 items = [1,2,3] with mutable(x, items): x = 3 items.append(4) # And now back to being immutable, these would error x = 5 items.append(6) I have put almost zero thought into the…

This is in essence a mutable borrow - by looking at Rust's borrow checker, one can see the complexities of the concept.

Re: John Carmack on mutable variables

#173

I like the idea of immutable-by-default, and in my own musings on this I've imagined a similar thing except that instead of a mutable keyword you'd have something more akin to Python's with blocks, something like: # Immutable by default x = 2 items = [1,2,3] with mutable(x, items): x = 3 items.append(4) # And now back to being immutable, these would error x = 5 items.append(6) I have put almost zero thought into the…

Without a borrowck, inside your mutable block, another variable can reference to the mutable version of your x or items, and be mutated outside of that block.

Re: John Carmack on mutable variables

#174

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.

Re: John Carmack on mutable variables

#175

There are languages nobody uses, and languages people complain about. Computing is about change, otherwise there is nothing to compute. The mere fact that its called a “variable” makes it obvious that its supposed to change.

This is a viewpoint commonly held by students who were exposed to imperative programming before having any class in maths. However it shouldn't survive long after that.

Re: John Carmack on mutable variables

#176
I don't mean to start a holy war, thats not the point, but isn't this a side effect of C++ footguns rather than python allowing you to be lazy?

I mean there is good reason to keep variables well scoped, and the various linters do a reasonable job about scope.

But I've only really know C++[1] people to want everything as a const.

[1] Yes, you functional people also, but, lets not get into that.

Re: John Carmack on mutable variables

#177
post #2

> Making almost every variable const at initialization is good practice. I wish it was the default, and mutable was a keyword. It's funny how functional programming is slowly becoming the best practice for modern code (pure functions, no side-effects), yet functional programming languages are still considered fringe tech for some reason. If you want a language where const is the default and mutable is a keyword, try…

Pure functional works great until it doesn't. For a lot of systems-y and performance-oriented code you need the escape hatches or you'll be in for a lot of pain and annoyance. As a practical observation, I think it was easier to close this gap by adding substantial functional capabilities to imperative languages than the other way around. Historically, functional language communities were much more precious about the…

> you need the escape hatches

Isn't this a strawman? Even Haskell has unsafePerformIO and Debug.Trace etc. It just also provides enough ergonomics that you don't need them so often, and they "light up" when you see them, which is what we want: to know when we're mutating.

Re: John Carmack on mutable variables

#178

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

[dead]

Re: John Carmack on mutable variables

#179

If designing your hypothetical ideal language, what are some intuitive/cute keywords you would choose for mutables/immutables? `let` is so 2020. `const` is too long. `static` makes me fall asleep at the keyboard. `con` sounds bad. How about `law`? law pi = 3.142 (heh typing on Mac autocompleted this) law c = 29979245 law law = "Dredd" or `set` or `once` or `make`?

There was a proposal in Java a few years back to introduce "val". I think it never gained traction but it would have been nice to have this in Java val firstName = "Bob"; val lastName = "Tables"; var fullName = ""; fullName = firstName + " " + lastName;

That's an aesthetically awkward and also bug-prone syntax: So just a difference of 1 single letter (that looks similar) to mean the completely opposite thing?? Nah you don't want that, and I don't either.

Re: John Carmack on mutable variables

#180
post #97
post #4

Years ago I did a project where we followed a lot of strict immutability for thread safety reasons. (Immutable objects can be read safely from multiple threads.) It made the code easier to read because it was easier to track down what could change and what couldn't. I'm now a huge fan of the concept.

You should check out Rust

Rust wasn't available at the time.

It probably won't come as a surprise to you, but I am a big fan of Rust.

Post reply on HN