John Carmack on mutable variables

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

Removing barriers to sloppy code is a language feature.

That is why vibe coding, JavaScript and Python are so attractive.

Removing barriers to civil engineering building design is a feature.

Who needs to calculate load bearing supports, walls, and floors when you can just vibe oversize it by 50%.

Well if it does the job. So what?

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

In the context of the original discussion, TypeScript (and ES6) has const and let.

Fair enough about const and let, the obnoxiousness for me is a combination of the language ergonomics, language ecosystem, but mostly the techno-political decision making behind it.

Neither let nor even const are immutable (const prevents reassignment but not mutation if the value is of a mutable type like object or array).

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

well yeah except const doesn't make objects or arrays immutable

I feel that Java’s “final” would have been a better choice than “const”. It doesn’t have the same confusing connotation.

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

You know I read this when it came out but have gotten out of the habit of applying it.

Thanks for the reminder. Will work on putting these ideas back into practice again.

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.

I remember that post and essentially agree with everything in it and your points too.

However there's a real-world factor that I don't think it covers, which is that having ten years of experience in the ecosystem for any language almost guarantees that you're going to be faster, more efficient, more idiomatic, and generally more comfortable through familiarity with that language and its ecosystem than with any other 'drop in replacement'. And you'll also probably be more aware of what doesn't work, which is just as useful. You can always tell when someone knows their tools well when they can immediately tell you what sucks about them, and possibly even the history of it and why it might happen to make sense, even if seems bad.

This isn't an argument for favouring speed or efficiency, just an ackowledgement of what is lost when you choose or are forced to move to a different environment.

Languages are a lot more than just syntax. Language-specific features, conventions and common idioms, language implementation details that end up being valuable to understand, familiarity with core library, familiarity with third party libaries (including the ones that are so well-known as to almost be considered core), package management, documentation standards, related tooling, foreign-function interfaces and related tools to make that workable, release concerns. The list goes on.

There's no tribal boundary here, just a belief that time spent with a given tool and all its idiosyncrancies (and programming languages are their idosyncracies, otherwise they wouldn't be different) is valuable and not something to pass up, even if I agree with the thesis of the article.

Can you bootstrap your way to a passable, possibly even idiomatic, solution with coding agents? Yes. Does that mean you've managed to short circuit the results of long-term experience? I'm not so sure. Does it matter? Depends on the person or environment, I guess.

I don't think the learning curve for a new tool is a straight line (I imagine more logarithmic), so it's not that you'd need the same amount of exposure in terms of time, but that does imply the cost of changing is up-front.

There's also a difference between choosing to investigate a new language out of your own interest and having the time to do it properly, versus having some top-down mandate that you must now use <X>, meanwhile still having to meet the same deadlines as before.

Yeah it makes their structure immutable? Something like that. Not useless but not what you would expect.

But for non-objects and non-arrays it's fine.

Yep, I believe you'd need to call Object.seal(foo) to prevent mutability. Haven't really had the chance to use it

Object.freeze is the one you're looking for.

const + Object.freeze is a lot to remember and cumbersome to use throughout a codebase, very relevant to Carmack's wish for immutability by default. I'm grateful Rust opted for that default.