I think the explanation is: When you mutate variables it implicitly creates an ordering dependency - later uses of the variable rely on previous mutations. However, this is an implicit dependency that isn't modeled by the language so reordering won't cause any errors.

With a very basic concrete example:

x = 7

x = x + 3

x = x / 2

Vs

x = 7

x1 = x + 3

x2 = x1 / 2

Reordering the first will have no error, but you'll get the wrong result. The second will produce an error if you try to reorder the statements.

Another way to look at it is that in the first example, the 3rd calculation doesn't have "x" as a dependency but rather "x in the state where addition has already been completed" (i.e. it's 3 different x's that all share the same name). Doing single assignment is just making this explicit.

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)]
    ...)

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).

Made a similar experience with Scheme. I could tell people whatever I wanted, they wouldn't really realize how much cleaner and easier to test things could be, if we just used functions instead of mutating things around. And since I was the only one who had done projects in an FP language, and they only used non-FP languages like Java, Python, JavaScript and TypeScript before, they would continue to write things based on needless mutation. The issue was also, that using Python it can be hard to write functional style code in a readable way too. Even JS seems to lend itself better to that. What's more is, that one will probably find oneself hard pressed to find the functional data structures one might want to use and needs to work around recursion due to the limitations of those languages.

I think it's simply the difference between the curious mind, who explores stuff like Clojure off the job (or is very lucky to get a Clojure job) and the 9 to 5 worker, who doesn't know any better and has never experienced writing a FP codebase.

The way I like to think about is that with immutable data as default and pure functions, you get to treat the pure functions as black boxes. You don't need to know what's going on inside, and the function doesn't need to know what's going on in the outside world. The data shape becomes the contract.

As such, localized context, everywhere, is perhaps the best way to explain it from the point of view of a mutable world. At no point do you ever need to know about the state of the entire program, you just need to know the data and the function. I don't need the entire program up and running in order to test or debug this function. I just need the data that was sent in, which CANNOT be changed by any other part of the program.

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's what they are doing.

In the end, the goal is always the same: better control and warranties about the impact of side effects with minimum fuss. Carmack approach here is sensible. You want practices which make things easy to debug and reason about while mainting flexibility where it makes sense like iterative calculations.

I would say it's more than immutability - it's the "feel" of working with values. I've worked with at least 6 languages professionally and likely more for personal projects over last 20 years. I can say that Clojure was the most impactful language I learned.

I tried to learn Haskel before but I just got bogged down in the type system and formalization - that never sat with me (ironically in retrospect Monads are a trivial concept that they obfuscated in the community to oblivion, yet another Monad tutorial was a meme at the time).

I used F# as well but it is too multi paradigm and pragmatic, I literally wrote C# in F# syntax when I hit a wall and I didn't learn as much about FP when I played with it.

Clojure had the lisp weirdness to get over, but it's homoiconicty combined with the powerful semantics of core data structures - it was the first time where the concept of working with values vs objects 'clicked' for me. I would still never use it professionally, but I would recommend it to everyone who does not have a background in FP and/or lisp experience.

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.

I guess I'm not that good a programmer, because I don't really understand why variables that can't be varied are useful, or why you'd use that.

How do you write code that actually works?

salutes from a WestLondonCoder

Here's a relevant comment on Rust: https://x.com/ID_AA_Carmack/status/1094419108781789184

You're using really generic terms which I have to think is mostly because you're talking about it in the abstract. In most scenarios I find there are obvious non-generic names I can use for each step of a calculation.

Yes, but there are often FP tricks and conveniences that make this unnecessary.

Like chaining or composing function calls.

result = x |> foo |> bar |> baz (-> x foo bar baz)

Or map and reduce for iterating over collections.

Etc.

result.process()

That doesn’t make logical sense. You already have a result. It shouldn't need processing to be a result.

> What is a "variable" if not something that varies?

If I define `function f(x) { ... }`, even if I don't reassign x within the function, the function can get called with different argument values. So from the function's perspective, x takes on different values across different calls/invocations/instances.

In the cases we're interested in here the variable does vary, what it doesn't do is mutate.

Suppose I have a function which sums up all the prices of products in a cart, the total so far will frequently mutate, that's fine. In Rust we need to mark this variable "mut" because it will be mutated as each product's price is added.

After calculating this total, we also add $10 shipping charge. That's a constant, we're (for this piece of code) always saying $10. That's not a variable it's a constant. In Rust we'd use `const` for this but in C you need to use the C pre-processor language instead to make constants, which is kinda wild.

However for each time this function runs we do also need to get the customer ID. The customer ID will vary each time this function runs, as different customers check out their purchases, but it does not mutate during function execution like that total earlier, in Rust these variables don't need an annotation, this is the default. In C you'd ideally want to label these "const" which is the confusing name C gives to immutable variables.

Right, yeah, it’s a funny piece of terminology! The sense in which a ‘variable’ ‘varies’ isn’t that its value changes in time, but that its value is context-dependent. This is the same sense of the word as used in math!

A common naming is value. You can call them immutable values and mutable variables.

Another way to look at it is a variables are separate from compile time constants whether you mutate them or not.

The term 'variable' is from mathematics. As others have said, the values of variables do vary but they do not mutate.

You are not a Clojure programmer. You use Clojure to solve problems in a professional context. I'm sorry that there's a political tribal war based on language going on at your workplace.

But especially now that coding agents are radically enabling gains in developer productivity, you don't need to feel excluded by the artificial tribal boundaries.

If you haven't, I recommend reading: https://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-pr...

Rust taught me that a language does not have to be purely functional to have everything be an expression, and ever since I first used Rust years ago I've been wishing every other language worked that way. It's such a nice way to avoid or limit the scope of mutations

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.

Clojure will always be faster than Python. So you have that, at least.

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 mutate arguments without it being obvious in the call syntax.

Are Rust's defaults far enough?

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);
        }
    }

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.

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.

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

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

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

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

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

My eyes would hurt more if I had to look all day at the vertical misalignment of that |> operator

Elixir too (Explorer library; default backend is Pola.rs based)

- https://github.com/elixir-explorer/explorer - https://hexdocs.pm/explorer/Explorer.html

pandas has a .pipe operator which works exactly like this

Wouldn't that be simply:

  df = pd.concat(df,other_df).select(...)

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

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.

JS's const doesn't go far enough since you can still mutate the object via its methods. In C++, you can only call const methods (which can't mutate the object) on const variables.

In JS, by using const, you are signalling to the reader that they don’t need to look out for a reassignment to understand the code. If you use let, you are saying the opposite.

You should check out Rust

The lovely thing with Haskell is you have the ST monad that lets you have as many mutable variables as you want, as long as they stay within ST.

How do you know it’s real? When one is in a straitjacket for a long time, the trauma might make the mind disassociate from the body, giving an illusion of freedom.

The brain is essentially dreaming it’s escaped while the body is still programming in Java.

How does Haskell deal with things like memory-mapped I/O or signal handlers where the value of a variable can be changed by factors outside of the programmer's control?

I've had this experience with going from PHP and JS to typed languages. Many years ago I was a type sceptic, but after being forced to use them, I now can't stand not having strict typing.

I'm sure others have written about this, but these days I think good code is code which has a very small area of variability. E.g code which returns a value in a single place as a single type, has a very limited number of params (also of single type), and has no mutable variables. If you can break code into chunks of highly predictable logic like this it's so so much easier to reason about your code and prevent bugs.

Whenever I see methods with 5+ params and several return statements I can almost guarantee there will be subtle bugs.

I have no doubt that he could, not only invent nuclear fusion, but get it running on a Pentium 90.

Sometimes it's nice to be reminded of some basic good ideas. Even if you already know. Also https://xkcd.com/1053/

How many hours of discussions went into topics like code formatting and naming things like variables, endpoints, classes, etc?

People worship this guy, but other than being a good C++ graphics programmer, it isn't clear what he's actually done.

I was part of the Carmack cult but the illusion was broken when I saw him use the same authoratative tone on a subject I'm more knowledgable about.

Just like AGI he was supposedly brought on board for but…..checks notes. Nothing.

It helps with that, but it has other trade-offs: indirection isn't free for readability.

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 purity of their functional-ness than imperative languages were about their imperative-ness.

> If you want a language where const is the default and mutable is a keyword, try F# for starters. I switched and never looked back.

Rust is also like this (let x = 5; / let mut x = 5;).

Or you can also use javascript, typescript and zig like this. Just default to declaring variables with const instead of let / var.

Or swift, which has let (const) vs var (mutable).

FP got there first, but you don't need to use F# to have variables default to constants. Just use almost any language newer than C++.

Agreed, and Carmack as always was ahead of the curve here.

In case anyone here hasn’t seen it, here’s his famous essay, Functional Programming in C++:

http://sevangelatos.com/john-carmack-on/

He addresses your point:

> I do believe that there is real value in pursuing functional programming, but it would be irresponsible to exhort everyone to abandon their C++ compilers and start coding in Lisp, Haskell, or, to be blunt, any other fringe language. To the eternal chagrin of language designers, there are plenty of externalities that can overwhelm the benefits of a language, and game development has more than most fields.

Functional programming languages (almost always?) come with the baggage of foreign looking syntax. Additionally, imperative is easier in some situations, so having that escape hatch is great.

I think that's why we're seeing a lot of what you're describing. E.g. with Rust you end up writing mostly functional code with a bit of imperative mixed in.

Additional, most software is not pure (human input, disk, network, etc), so a pure first approach ends up being weird for many people.

At least based on my experience.

We are still living with the hangover of C, which was designed for the resource-starved machines of eons ago, and whose style later languages felt they had to copy to get any kind of adoption. (And as you point out, that is how things turned out.)

My bet is functional programming will become more and more prevalent as people figure out how to get AI-assisted coding to work reliably. For the very reasons you stated, functional principles make the code modular and easy to reason about, which works very well for LLMs.

However, precisely because functional programming languages are less popular and hence under-represented in the training data, AI might not work well with them and they will probably continue to remain fringe.

> It's funny how functional programming is slowly becoming the best practice for modern code (pure functions, no side-effects),

I once mentioned both these concepts to a room of C# developers. Two of them were senior to me and it was a blank expression from pretty much everyone.

> yet functional programming languages are still considered fringe tech for some reason.

You can use the same concepts in non-functional programming languages without having to buy into all the other gumpf around functional programming languages. Also other programming languages have imported functional concepts either into the language itself or into the standard libraries.

Past that. It is very rare to be able to get a job using them. The number of F# jobs I've seen advertised over the last decade, I could count on one hand.

I’ve done a significant amount of functional programming (including F#) and still reach for it sometimes, but I don’t think it provides substantial advantages for most use-cases. Local mutability is often clearer and more maintainable.

Also, category theorists think how excited people get about using the word monad but then most don’t learn any other similar patterns (except maybe functors) is super cringe. And I agree.

It's because you want a tasteful mix of both.

I believe Scala was pretty ahead here by building the language around local mutability with a general preference for immutable APIs, and I think this same philosophy shows up pretty strongly in Rust, aided by the borrow checker that sort of makes this locality compiler-enforced (also, interior mutability)

one thing I've learned in my career is that escape hatches are one of the most important things in tools made for building other stuff.

dropping down into the familiar or the simple or the dumb is so innately necessary in the building process. many things meant to be "pure" tend to also be restrictive in that regard.

While it's amusing, I think it's sensible: One of the main tasks in most businessy programming is to take what a human wants, translate it to code, reverse-translate it back to human understanding later, modify it, and translate it again to slightly different code.

This creates friction between casual stakeholder models of a mutable world, versus the the assumptions an immutable/mostly-pure language imposes. When the customer describes what they need, that might be pretty close to a plain loop with a variable that increments sometimes and which can terminate early. In contrast, it maps less-cleanly to a pure-functional world, if I'm lucky there will at least be a reduce-while utility function, so I don't need to make all my own recursive plumbing.

So immutability and pure-functions are like locking down a design or optimizing--it's not great if you're doing it prematurely. I think that's why starting with mutable stuff and then selectively immutable'ing things is popular.

Come to think of it, something similar can be said about weak/strong typing. However the impact of having too-strong typing seems easier to handle with refactoring tools, versus the problem of being too-functional.

> If you want a language where const is the default and mutable is a keyword

whats the difference between const and mutable?

I think it's because (I'm looking at Haskell in particular) there are a lot of great ideas implemented in them, but the purity makes writing practical or performant time-domain programs high friction. But you don't need both purity and the various tools they provide. You can use the tools without the pure-functions model.

In particular: My brain, my computing hardware, and my problems I solve with computers all feel like a better match for time-domain-focused programming.

Don't get too comfortable, history likes oscillation. If it becomes the norm then someone will have a "actually writing imperatively makes things go super fast".

functional programming has a lot of wonderful concepts, which are very interesting in theory, but in practice, the strictness of it edges on annoying and greatly hurts velocity.

Python has a lot of functional-like patterns and constructs, but it's not a pure functional language. Similarly, Python these days allow you to adds as much type information as you want which can provide you a ton of static checks, but it's not forced you like other typed languages. If some random private function is too messy to annotate and not worth it, you can just skip it.

I like the flexibility, since it leads to velocity and also just straight up more enjoyable.

It’s because FP, great as it is, is most beneficial when 80/20’d.

Trying to do it 100% pure makes everything take significantly longer to build and also makes performance difficult when you need it. It’s also hard to hire/onboard people who can grok it.

Const by default is not functional programming.

I get your sentiment, but I side on it's infuriating that it's taken this long. Lol.

F# is wonderful. It is the best general purpose language, in my opinion. I looked for F# jobs for years and never landed one and gave up. I write Rust now which has opened up the embedded world, and it's nice that Rust paid attention to F# and OCaml.

Decades of blog posts, articles and books about "best practices" led to a suspicion of anything that wasn't bog standard OOP. This site in particular has also contributed to that, especially in the early 2000s, where you can easily find comments disparaging FP.

So essentially he gives 2 arguments:

1) You get intermediate results visible in the debugger / accessible for logs, which I think is a benefit in any language.

2) You get an increased safety in case you move around some code. I do think that it applies to any language, maybe slightly more so in C due to its procedural nature.

See, the following pattern is rather common in C (not so much in C++):

- You allocate a structure S

- If S is used as input, you prefill it with some values. If it's used as output, you can keep it uninitialized or zfill.

- You call function f providing a pointer to that struct.

Lots of C APIs work that way: sockets addresses, time structures, filesystem entries, or even just stack allocated fixed size strings are common.

Same here, I grew up in a world where you had a handful of registers and a bunch of memory locations, and those were your variables.

                clc
                lda value
                adc #1
                sta value
                lda value+1
                adc #0
                sta value+1

    value       .byte 0,0

    x = 20
    x = x + func(y)
    x = x / func(z)

    x = 20
    x1 = x + func(y)
    x2 = x1 / func(z)

Compiler optimizations make up for it, usually. Thats been my experience at least.

An important thing to keep in mind is just how far compilers have come over the least 40 years. Often, with immutable languages, they can do extremely efficient compile only optimizations because of said guaranteed immutability by default.

Its not true in every case, of course, but I think for most situations compilers do a more than good enough job with this.

I think he's just saying that mutation is ok if it's something loopy, like changing the loop counter or updating some running sum. So both i+=1 and ++i are fine.

To be fair, Carmack has advocated for immutability and other good practices at least since the 2000s.

I still have a habit of naming variables foo0, foo1, foo2, from a time working in Erlang many years ago.

It's also really funny, since C++ is like a malicious genie with this. The author wished for mutable to be a keyword, and C++ made the wish come true: it's a keyword that removes some of the guarantees of const!

Go desperately needs support for immutable structs that copy cleanly.

I want to be able to write `x := y` and be sure I don't have mutable slices and pointer types being copied unsafely.

I would kill for an immutable error type

Go is the new PHP.

An order of magnitude? That sounds like pretty outrageous hyperbole. A variable getting reassigned 10 times sounds extremely rare, the average in my experience has to be less than 1 reassignment. I think the approach requires coming up with maybe 10% more names.

Usually there are good, obvious names for intermediate calculations in my experience.

I'm open though - what kinds of things are you doing that require reassigning variables so much?

No, not at all. You still have the advantages of scopes, name shadowing, namespaces, and collection types. If your language supports them, you can also use algebraic data types to further reduce the number of names you need to deal with.

Either you don't understand what you're talking about, or you've missed the word "strive" in the tweet.

For performance critical code, you wouldn't use malloc()-allocation at all, though whether using an arena allocator or putting stuff on the stack, your argument is still sane. Data locality is speed.

"Immutability" from a programming language statement perspective doesn't necessarily imply that the implementation duplicates memory or variables.

Similar to how "tail recursion can (usually) be lifted/lowered to a simple loop...", immutability from language statements can often be "collapsed" into mutating a single variable, and there may be one or two "dances" you need to do to either add helper functions, structure your code _slightly_ differently to get there, but it's similar to any kind of performance sensitive code.

Example foo(bar(baz(), bar_alt(baz_alt(), etc...))) [where function call nesting is "representing" an immutability graph] ...yeah, that'd have a lot of allocations and whatever.

But: foo().bar().bar_alt().baz().baz_alt().etc(...) you could imagine is always just stacking/mutating the same variable[s] "in place".

...don't get hung up on the syntax (it's wildly wrong), but imagine the concept. If all the functions "in the chain" are pure (no globals, no modifications), then they can be analyzed and reduced. Refer back to the "Why SSA?" article from a week or two ago: https://news.ycombinator.com/item?id=45674568 ...and you'll see how the logical lines of statements don't necessarily correspond to the physical movement of memory and registers.

> I use Javscript mostly. Or Typescript actually, these days. I remember when ES2015 introduced `let` because `var` had weird scoping issues. But ever since, I barely use either of them. Everything is `const` these days, as it should. reply

const prevents reassignment of the variable but it does not make the object the variable points to immutable.

To do the latter, you have to use Object.freeze (prevent modification of an object’s properties, but it is shallow only so for nested objects you need to recurse) and Object.seal (prevent adding or removing properties, but not changing them).

May people use immutable.js or Immer for ergonomic immutable data structures.

`var` doesn't have weird scoping issues, it just different than other languages. `var` is function scoped, thus all var declarations are hoisted to the top of the function during execution.

This is why the single var pattern used to be recommended.

Except const is not sufficient. It will prevent the reference from being reassigned but the const can still reference a mutable object.

This is only for redefinitions that change the type. If you re-assign with the same type, there's no warning. However, pylint does issue warnings for other interesting cases, such as redefining function arguments and variables from an outer scope.

> But it's a little too verbose to just sprinkle on every variable in C++

It's worth it, though. Every variable that isn't mutated should be const. Every parameter not mutated should be const, and so should every method that doesn't mutate any fields. The mutable keyword should be banned.

100%, life's too short.

Ultra-pedantic const-correctness (vs tasteful const-correctness on e.g. pass-by-reference arguments or static/big objects) catches nearly no bugs in practice and significantly increases the visual noise of your code.

If you have luxury of designing a new language or using one with default mutability then do so, but don't turn C coding styles into C++-envy, or C++ coding styles into Rust-envy.

If they're representing different data from different API calls, yeah, I'd be strongly inclined to give them different names.

    order_data = boto.get_from_dynamodb()
    customer_data = boto.get_from_rds()
    branding_assets = boto.get_from_s3()
    return render_for_user(order_data, customer_data, branding_assets, ...)

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.

Carmack had said he likes rust, he just isn't a language zealot. In rust though, the idiom would be to shadow intermediate variables often, which removes the debugger benefit.

not if it gets optimized out

For the same reason almost all my functions end with this:

  const result = ... ;
  return result;

A real default doesn’t need a keyword.

I believe the standard counterargument goes:

- either it's transitive, in which case your type system is very much more complicated

- or it isn't, in which case it's a near useless liability

Naturally C++ runs with the latter, with bonus extra typing for all the overloads it induces.

He also stopped shipping things.

There’s no mutating happening here, for example:

  if cond:
      X = “yes”
  else:
      X = “no”

  let X = if cond { “yes” } else { “no” };

For what it's worth, I was experimenting with this idea for Python (in an almost completely vibe-coded fashion) here: https://github.com/jlmcgraw/pure-function-decorators

Whether it's of any actual utility is debatable

JavaScript’s `const` has the bigger issue that while things can’t be reassigned, they can still mutate. For example:

  const myArray = [1,2,3]
  myArray.push(4)
  myArray // [1, 2, 3, 4]

You could do an absolutely disgusting IIFE if you need the curly brace spice in your life, instead of a typical JS ternary.

  const y = (() => {
    if (x) {
      return true;
    } else {
      return false;
  })();

Why not do:

const y = x ? true : false;

Ditto. These days those are the only cases where I use "let" in JS. The thing I miss most from Kotlin is the ability to return values from blocks, e.g.

val result = if (condition) { val x = foo() y = bar(x) y + k // return of last expression is return value of block } else { baz() }

Or:

val q = try { a / b } catch (e: ArithmeticException) { println("Division by zero!") 0 // Returns 0 if an exception occurs }

Edit: ugh, can't get the formatting to work /facepalm.

Going too hard on mutation means you usually end up with larger structures that are recreated completely. Those themselves are then the point of mutation. This can be helpful if the larger object needs a lot of validation and internal cross rules (eg. You can't set 'A' if 'B' is true, you can validate that when recreating the larger object whereas if 'A' was mutable on it's own someone might set it and cause the issue much later which will be a pain to track down).

Anyway the outcome of trying to avoid mutation means instead of simply setting player.score you get something like player = new Player(oldPlayerState, updates). This is of course slow as hell. You're recreating the entire player object to update a single variable. While it does technically only mutate a single object rather than everything individually it's not really beneficial in such a case.

Unless you have an object with a lot of internal rules across each variable (the can't be 'A' if 'B' example above) it's probably wrong to push the mutation up the stack like that. The simple fact is a complex computer program will need to mutate something at some point (it's literally not a turing machine if it can't) so when avoiding mutation you're really just pushing the mutation into a higher level data object. "Avoid mutations of data that has dependencies" is probably the correct rule to apply. Dependencies need to be bundled and this is why it makes sense not to allow 'A' in the above example to be mutated individually but instead force the programmer to update A and B together.

That depends on your definition. Programming languages often deviate from mathematics when it comes to definition of variables, functions etc. That is by choice, Haskell tried to be as close to mathematical definition as possible.

A constant is a variable that _always_ has the same value on all lifecycles, e.g.

    const int a{10};

   void some_function(const int a);

Depends on how you look at it.

A true constant won't change between runs of the code. I.e. it is essentially a symbolic name for a literal.

A constant variable OTOH, varies in different executions of the code. So, its invariance is linked to an execution context.

What about the result of a computation within a giant algorithm that I decided to name, and don't plan on rewriting it anymore?

That's surely not a constant like PI, is it?

Maybe the new C++ profiles that are supposedly going to make C++ a safe language could do it.

Could be a compiler flag. -const-by-default. Would probably mean you need to scatter mutable across the codebase to get it to compile, but I expect some people would like to have every local annotated as const or mutable.

They could just add a "use immutable;" directive that you place at the top of your file.

cpp2/cfront could plausibly do this, right? Except he doesn't want to:

https://github.com/hsutter/cppfront/wiki/Design-note%3A-cons...

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;

What is wrong with let?

I hope this experimental language becomes usable eventually, all I hear is how you have to continuously rewrite to work around the borrow checker, accept worse performance to make everything message based, or just ignore the type system and write VB6-style code where everything is indexes in arrays to obfuscate ownership and paste 'unsafe' when it moans.

Eh, Rust is kind of "immutable by default" but not really enforcing that + "constants" in the way I think Carmack advocates for. Other languages does better in that regard. Examples: https://play.rust-lang.org/?version=stable&mode=debug&editio...

blojo? Ask him and report back.

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.

Bjarne's excuse is very silly, it's like the Laffer curve but for programming language defects. It pins one edge case nobody cares about, then tries to imply that's proof for a claim no sane person could agree with and for which there is no evidence. Bjarne says languages with no users attract no complaints regardless of how terrible they are (nobody was arguing that they do), therefore implies Bjarne, the fact that people complain about my language just means it is popular. Bzzt, wrong. They're complaining because it's so riddled with problems.

Variables are distinct from constants. It's a problem that C and C++ use the keyword "const" to signify immutability instead, indeed as a result C++ needed three more keywords "constexpr", "constinit" and "consteval" to try to grapple with the problem.

> I want everything that passes through a function to be a copy unless I put in a symbol or keyword that it suppose to be passed by reference.

JavaScript doesn’t have references, it is clearer to only use “passed by reference” terminology when writing about code in a language which does have them, like C++ [0].

In JavaScript, if a mutable object is passed to a function, then the function can change the properties on the object, but it is always the same object. When an object is passed by reference, the function can replace the initial object with a completely different one, that isn’t possible in JS.

Better is to distinguish between immutable objects (ints, strings in JS) and mutable ones. A mutable object can be made immutable in JS using Object.freeze [1].

[0] https://en.wikipedia.org/wiki/Reference_(C%2B%2B)

[1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

It is a similar idea to what Carmack is writing about. Golang, Clojure does something similar to what I am talking about above so not sure of the motivation behind the voting down of the comment.

Problem is that "copy" of an object is not well defined. It could be a "shallow" copy or a "deep" copy. The only models where "copy" is defined are simple "memory"/"value" models (like C) and immutable models (like Haskell).