John Carmack on mutable variables

> 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, list, set, listOf, array, vector, arrayOf, Array.of(), etc unless it's going to get in my way because I have ten CPU cores and I'll optimize the loop when I need to.

I don’t have any useful ideas here but if you make a linter for this sort of thing, I suggest calling it “mutalator.”

Your IDE probably supports this as an explicit action. JetBrains has a feature that can find all reads and writes to a variable

I use Swift for work. The compiler tell you this. If a mutable variable is never mutated it suggests making it non-mutable. And vice versa.

I don't think this is the best option, there could be very hard bugs or performance cliffs. I think I'd rather have an explicit opt-in, rather than the abstraction changing underneath me. Have my IDE scream at me and make me consider if I really need the opt-in, or if I should restructure.

Although I do agree with the sentiment of choosing a construct and having it optimize if it can. Reminds me of a Rich Hickey talk about sets being unordered and lists being ordered, where if you want to specify a bag of non-duplicate unordered items you should always use a set to convey the meaning.

It's interesting that small hash sets are slower than small arrays, so it would be cool if the compiler could notice size or access patterns and optimize in those scenarios.

Right, sql optimizers are a good example - in theory it should "just know" what is the optimal way of doing things, but because these decisions are made at runtime based on query analysis, small changes to logic might cause huge changes in performance.

Clang-tidy's misc-const-correctness warns for this. Hook it up to claude code and it'll const all non mutated mutables.

As will Typescript, at least using Biome to lint it does.

It also has the ability to style mutated variables differently.

If you write in erlang, emacs does this by default ;)

Yes, depending on your highlighting scheme. Not every highlighting scheme shows this by default, unfortunately.

To me, this seems initially like some very minor thing, but I find this very helpful working with non-trivial code. For larger methods you can directly discern whether a not-as-immutable-declared variable behaves immutable nonetheless.

Yup, it's pretty great. You get into the habit of suspiciously eyeing every variable that's not a constant.

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 < 20; ++def)
        {
            System.out.print(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 maintainable code, that is easier to read.

Could Pylint help? It has atleast check for variable redefinition: https://pylint.pycqa.org/en/latest/user_guide/messages/refac...

1st) you use ++def in a loop, don't be weird; 2nd) if 'abc' is to be used in the loop body, define in the loop, e.g. for (int def = 7, abc =3; ...); 3rd) this is an IntelliJ bug - both 'def' and 'abc' in the sample are always defined.

3) looks like you read 'underlined' as 'undefined'

true that, thanks!

the only thing that is weird is your lack of understanding temporary variables

perhaps... yet, Java doesn't have a definition for temporary variables

eslint has this too: https://eslint.org/docs/latest/rules/prefer-const

As an aside, you might also enjoy the inline inferred annotations.

https://www.jetbrains.com/help/idea/annotating-source-code.h...

Seeing @NotNull in there even if the author hasn't specifically written that can help in understanding (and not needing to consider) various branches.

My very minor complaint about TypeScript is you use to use `const` which is 2 additional letters.

Seriously though, I do find it slightly difficult to reason about `const` vars in TypeScript because while a `const` variable cannot be reassigned, the value it references can still be mutated. I think TypeScript would benefit from more non-mutable values types... (I know there are some)

Swift has the same problem, in theory, but it's very easy to use a non-mutable value types in Swift (`struct`) so it's mitigated a bit.

This works in RustRover as well! Super useful.

Rust's type system specifically facilitates more powerful tools: https://github.com/willcrichton/flowistry

For type only though.