In other words, he wishes he used Rust.
John Carmack on mutable variables
451–460 of 663 posts
Re: John Carmack on mutable variables
#452Earlier quoted context omitted.
That’s the point, you’re just haggling about scopes now. All the way from being new per program invocation to new per loop. Immutability doesn’t have this connotation.
How? I think the same argument applies: If it's changing from loop to loop, seems mutable to me.
I think you’re after something other than immutability then.
You’re allowed to rebind a var defined within a loop, it doesn’t mean that you can’t hang on to the old value if you need to.
With mutability, you actively can’t hang on to the old value, it’ll change under your feet.
Maybe it makes more sense if you think about it like tail recursion: you call a function and do some calculations, and then you call the same function again, but with new args.
This is allowed, and not the same as hammering a variable in place.
Re: John Carmack on mutable variables
#453Re: John Carmack on mutable variables
#454Earlier quoted context omitted.
Yet even Rust allows you to shadow variables with another one with the same name. Yes, they are two different variables, but for a human reader they have the same name. I think that Rust made this decision because the x1, x2, x3 style of code is really a pain in the ass to write.
In idiomatic Rust you usually shadow variables with another one of the same name when the type is the only thing meaningfully changing. For example let x = "29" let x = x.parse:: () let x = x.unwrap() These all use the same name, but you still have the same explicit ordering dependency because they are typed differently. The first is a &str, the second a Result , the third an i32, and any reordering of the lines woul…
Another idiomatic pattern is using shadowing to transform something using itself as input:
let x = Foo::new().stuff()?; let x = Bar::new(x).other_stuff()?;
So with the math example and what the poster above said about type changing, most rust code I write is something like:
let x: plain_int = 7
let x: added_int = add(x, 3);
let x: divided_int = divide(x, 2);
where the function signatures would be fn add(foo: plain_int, int); fn divide(bar: added_int, int);
and this can't be reordered without triggering a compiler error.
Re: John Carmack on mutable variables
#455I 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.
Yes, and math has the notion of "free variable" and "bound variable" [1].
[1] https://en.wikipedia.org/wiki/Free_variables_and_bound_varia...
Re: John Carmack on mutable variables
#456> I wish it was the default, and mutable was a keyword. I wish the IDE would simply provide a small clue, visible but graphically unobtrusive, that it was mutated . In fact, I end up wishing this about almost every language feature that passes my mind. For example, I don't need to choose whether I can or can't append to a list; just make it unappendable if you can prove I don't append. I don't care if it's a map, lis…
In my IntelliJ (a recent version), if I write a small Java function like this: private static void blah() { final int abc = 3; for (int def = 7; def The variable 'def' is underlined. Mouse-over hint shows: 'Reassigned local variable'. To be clear, 'abc' is not underlined. When I write Java, I try to use the smallest variable scopes possible with as much final (keyword) as possible. It helps me to write more maintaina…
This works in RustRover as well! Super useful.
Re: John Carmack on mutable variables
#457Earlier quoted context omitted.
Carmack is talking about variable reassignment here, which Clojure will happily let you mutate. For example: (let [result {:a 1} result (assoc result :b 2)] ...) He mentions that C and C++ allow const variables, but Clojure doesn't support that. clj-kondo has a :shadowed-var rule, but it will only find cases where you shadow a top-level var (not the case in my example).
It's more nuanced, because the shadowing is block-local, so when the lexical scope exits the prior bindings are restored. I think in practice this is the ideal middle ground of convenience (putting version numbers at the end of variables being annoying), but retaining mostly sane semantics and reuse of prior intermediate results.
[deleted]
Re: John Carmack on mutable variables
#458Earlier quoted context omitted.
My eyes would hurt more if I had to look all day at the vertical misalignment of that |> operator
You could always switch to a better font like Fira Code which has a ligature for this.
The gp's comment wasn't made regarding the look of the operator in its ascii representation `|>` but about the vertical misalignment.
Typically you align a pipeline like so:
df
|> rbind(other_df)
|> select(...)
Re: John Carmack on mutable variables
#459Agree. After working seriously on a large production Haskell codebase for several years I definitely took it for granted. Now that I’m writing stuff in C again I do think immutability should be the default. const isn’t really it though. It could go further.
Well in C actually you can not mutate something, you can only reassign, as it is always pass-by-value. You need to work around that, by passing a pointer to the object instead. In that sense mutability is kind of a language keyword: '&'. When you want to just get the object, you pass object it, if you need to modify it, you need to pass &object. This is something I hate in C++, that random function invocations can mu…
I think that's why the * is generally preferred over the & for this purpose. It also can give some hints about ownership issues. This "pass by reference" thing is syntactic sugar and sometimes is great to have, but as Perlis said, "Syntactic sugar causes cancer of the semicolon" [1].