Totally agree. const auto for me is the default.
John Carmack on mutable variables
511–520 of 663 posts
Re: John Carmack on mutable variables
#512After 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 think the advantage is often oversold and people often miss how things actually exist on a continuum and just plainly opposing mutable and immutable is sidestepping a lot of complexity. For exemple, it's endlessly amusing to me to see all the efforts the Haskell community does to basically reinvent mutability in a way which is somehow palatable to their type system. Sometimes they even fail to even realise that it'…
>For exemple, it's endlessly amusing to me to see all the efforts the Haskell community does to basically reinvent mutability in a way which is somehow palatable to their type system.
That's because Haskell is a predominantly a research language originally intended for experimenting with new programming language ideas.
It should not be surprising that people use it to come up with or iterate on existing features.
Re: John Carmack on mutable variables
#513Earlier quoted context omitted.
If you need new values you just make new things. If you want to do an operation on fooA, you don't mutate fooA. You call fooB = MyFunc(fooA) and use fooB. The nice thing here is you can pass around pointers to fooA and never worry that anything is going to change it underneath you. You don't need to protect private variables because your internal workings cannot be mutated. Other code can copy it but not disrupt it.
> If you want to do an operation on fooA, you don't mutate fooA. You call fooB = MyFunc(fooA) and use fooB. This is the bit I don't get. Why would I do that? I will never want a fooA and a fooB. I can't see any circumstances where having a correct fooB and an incorrect fooA kicking around would be useful.
As Carmack points out, naming the intermediate values aides in debugging. It also helps you write code as you can give a name to every mutation.
But also keep in mind that correct and incorrect is not binary. You might want to pass a fooA to another class that does not want the fooB mutation.
If you just have foo, you end up with situations where a copy should have happened but didn't and then you get unwanted changes.
Re: John Carmack on mutable variables
#514> 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…
I want a language that helps me write software. I do not need a language that's hellbent on expressing a particular ideology.
Re: John Carmack on mutable variables
#515After 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.
the flash of enlightment I had when I understood the incredible power the rules of functional programming give you as a coder is probably the biggest one I've had in my career so far. idempotence, immutability and statelessness on their own let you build a thing once in a disciplined way and then use it all willy nilly anywhere you want without having to think about anything other than "things go into process, other things come out" and it's so nice.
Re: John Carmack on mutable variables
#516I 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?
I try to avoid this ambiguity by calling such variables "values".
Re: John Carmack on mutable variables
#517Earlier quoted context omitted.
The concept is actually pretty simple: instead of changing existing values, you create new values. The classic example is a list or array. You don't add a value to an existing list. You create a new list which consists of the old list plus the new value. [1] This is a subtle but important difference. It means any part of your program with a reference to the original list will not have it change unexpectedly. This eli…
> It means any part of your program with a reference to the original list will not have it change unexpectedly. I don't get why that would be useful. The old array of floats is incorrect. Nothing should be using it. That's the bit I don't really understand. If I have a list and I do something to it that gives me another updated list, why would I ever want anything to have the old incorrect list?
State exists in time, a variable is usually valid at the point it's created but it might not be valid in the future. Thus if part of your program accesses a variable expecting it to be from a certain point in time but it's actually from another point in time (was mutated) that can cause issues.
Re: John Carmack on mutable variables
#518How fast this got to the top, you would think John Carmack just invented nuclear fusion.
Right? This isn't even a hot take - it's just standard software engineering advice we all learn in school or on the job.
Re: John Carmack on mutable variables
#519Yeah 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
As a Python programmer at day job, that is Clojure-curious and sadly only gets to use it for personal projects, and is currently threatened by an obnoxious TypeScript take over, I feel this.
If you avoid metaprogramming and stick to the simple stuff, python and typescript are almost the same language.
To be fair, comprehensions (list/object expresions) are a nice feature that I miss a lot in JS/TS. But that's about it.
Re: John Carmack on mutable variables
#520I try to keep deeper mutation to where it belongs, but I'll admit to shadowing variables pretty often. If I have a `result` and I need to post-process it. I'm generally much happier doing `result = result.process()` rather than having something like `preresult`. Works nicely in cases where you end up moving it into a condition, or commenting it out to test an assumption while developing. If there's an obvious name fo…
> result.process() What result? What process? ...says every person who has to read your code later.
I mean, it's probably pretty clear when you look at result's initial assignment...