https://nitter.net/id_aa_carmack/status/1983593511703474196
I wish this was one of HN's auto formatting rules, automatically replace the link with one of these frontends
John Carmack on mutable variables
601–610 of 663 posts
Re: John Carmack on mutable variables
#602Earlier 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."
In python there's no let, var nor const. So yes.
Re: John Carmack on mutable variables
#603Earlier 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.
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 its prototype to point to something else and completely change its inheritance chain. And it could be a const variable to an unfrozen POJO all along.
That is not an exception to how things work, its how every reference works.
Re: John Carmack on mutable variables
#604After 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 spent some time discussing in another thread discussing why the foreach loop is so bad in many languages. Most of the bugs I write come from me managing state, yet if I want to do much more than going start to end of a collection I have to either use methods that are slower than a proper loop or I have to manage all the state myself.
In common lisp you have the loop macro (or better: iterate), in racket you have the for loops. I wrote a thing for guile scheme [0]. Other than that I dont know if many nice looping facilities. In many languages you can achieve all that with conbinatoes and what not, but always at the cost of performance.
I think this is an opportunity for languages to become safer and easier to use without changing performance.
Re: John Carmack on mutable variables
#605If 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`?
Why not "def"?
That's fine. But couldn't that just mean "define" any value at all?
There's nothing in it to say it's specifically for defining a value only ONCE.
Re: John Carmack on mutable variables
#606Earlier quoted context omitted.
If you start programming in it though, syntax only matters during the first day. Familiarity comes very fast, and if you do five programming exercises, maybe one a day, 'implement a hash map', 'make a small game', etc. you will have no problems whatsoever once the week is done. If you have a course where one day you're supposed to do Haskell and another Erlang, and another LISP, and another Prolog, and there's only o…
This is far from true in my experience. I'm no Lisp hater (I wrote a self-compiling compiler in Scheme) but different syntaxes have dramatically different degrees of familiarity, like Latin letters and Cyrillic. How long do you think it would take you to learn to read phonetically in Cyrillic as fast as you do in the Latin script? It takes the humans months or years, if they ever arrive. But, also, some notations are…
I shouldn't have mentioned LISP because I don't use it and I actually find the parentheses to be annoying, but it's a paradigm and you need them. Cyrillic at full speed is obviously weeks. But Erlang is very math-notation-y and when I introduced people to some Erlang code I'd written they understood it once I'd given a presentation on it and were then able to do similar things.
Re: John Carmack on mutable variables
#607Earlier quoted context omitted.
I spent a decade or so working on video codecs with an international team, and there was sort of an unwritten rule that code shouldn’t have comments and variable names shouldn’t be descriptive (english language couldn’t be assumed). Which sounds really awful, but after a while it forces you to parse the logic itself instead of being guided by possibly-out-of-date comments and variable names. I now prefer less verbosi…
This is kind of the opposite of LLMs, they seem to derive meaning mostly from the variable names, not from what the code actually does.
I haven’t noticed that, will have to keep an eye out. Could help explain some quality inconsistencies.
Re: John Carmack on mutable variables
#608Earlier quoted context omitted.
"const" means something can't be changed. "mutable" means it can be changed. You don't need both a "const" keyword and a "mutable" keyword in a programming language. You only need 1 of the keywords, because the other can be the default. munchler is saying the "const" keyword shouldn't exist, and instead all variables should be constant by default, and we should have a "mutable" keyword to mark variables as mutable. A…
> you don't need both a "const" keyword and a "mutable" keyword What if the lang has pointers? How express read-only?
You can make everything read-only by default, and if you need non-read-only, you use "mutable".
Re: John Carmack on mutable variables
#609Earlier quoted context omitted.
Immutable and constant are the same. rendaw didn't use the word mutable. One reason someone might use the word "mutable" is that it's a succinct way of expressing an idea. Alternative ways of expressing the same idea are longer words (changeable, non-constant).
but we already had the word variable for values that can change. on both counts it seems redundant
Oh, good point. I misunderstood your previous question.
Is there a name that refers to the broader group that includes both constants and variables? In practice, and in e.g. C++, "variable" is used to refer to both constants and actual variables, due to there not being a different common name that can be used to refer to both.
Re: John Carmack on mutable variables
#610Earlier quoted context omitted.
The hardware that these programs are running on store objects in linear memory, so it doesn't not make sense to treat it as such.
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 renaming scheme, where the register file at microarchitecture level is larger than that described in the software-level architecture reference, i.e. one instruction's "r7" has no relationship at all to another's r7".
Caches aren't quite as mix-and-match, but they can still internally manage different temporal versions of a cache line, as well as (hopefully) mask the fact that a write to DRAM from one core isn't an atomic operation instantly visible to all other cores.
Practice is always more complicated than theory.