Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

John Carmack on mutable variables

twitter.com

Post reply on HN
Print view View original

581–590 of 663 posts

Re: John Carmack on mutable variables

#581

Post by kec »

adregan wrote: post #458
kec wrote: post #357

Earlier quoted context omitted.

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(...) But these topics are largely left to code formatters these days.

Weird, I have always aligned as the gp showed. I’m reasonably sure tidyverse documentation does the same (which is probably where we both picked it up from).

Re: John Carmack on mutable variables

#582

Post by maleldil »

stevage wrote: post #537
maleldil wrote: post #415

Earlier quoted context omitted.

Because this isn't immutability. The goal is to have a way to define an object that will never change after initialisation, and JS's const isn't it.

Clearly that isn't the goal.

By "the goal", I mean TFA's, not JS's.

Re: John Carmack on mutable variables

#583

Post by maleldil »

loeg wrote: post #555
maleldil wrote: post #408

Earlier quoted context omitted.

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

Const annotations are worth it for methods and APIs, but not most local variables.

I'd argue that it is. Use const by default, so it's obvious to the reader if something is mutated or not. It's easier to read code when you don't have to worry about how values may change over time. This is why Rust made the right choice.

Re: John Carmack on mutable variables

#584

Post by mwcz »

Kailhus wrote: post #568
dragonwriter wrote: post #288

Earlier quoted context omitted.

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

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.

Re: John Carmack on mutable variables

#585

Post by jimbokun »

ErroneousBosh wrote: post #563
jimbokun wrote: post #523

Earlier quoted context omitted.

You pass in an array to a function meant to perform a transformation on each item of the array and return the result. You pass in an array of 10 values. While the function is executing, some other thread adds two more values to the array. How many values should the result of the function call have? 10 or 12? How do you guarantee that is the case?

> While the function is executing, some other thread adds two more values to the array. This is not something that can happen.

Why not? Which language?

Re: John Carmack on mutable variables

#587

Post by DemocracyFTW2 »

bmacho wrote: post #544
supergarfield wrote: post #535

Earlier quoted context omitted.

Carmack gives updating in a loop as the one exception: > You should strive to never reassign or update a variable outside of true iterative calculations in loops. If you want a completely immutable setup for this, you'd likely have to use a recursive function. This pattern is well supported and optimized in immutable languages like the ML family, but is not super practical in a standard imperative language. Something…

You don't have to use recursion, that is, you don't need language support for it. Having first class (named) functions is enough. For example you can modify sum such that it doesn't depend on itself, but it depends on a function , which it will receive as argument (and it will be itself). Something like: def sum_(f, l): if not l: return 0 return l[0] + f(f, l[1:]) def runreq(f, *args): return f(f, *args) print(runreq…

> You don't have to use recursion

You're using recursion. `runreq()` calls `sum_()` which calls `sum()` in `return l[0] + f(f, l[1:])`, where `f` is `sum()`

Re: John Carmack on mutable variables

#588

Post by DemocracyFTW2 »

everforward wrote: post #315
a4isms wrote: post #223

Earlier quoted context omitted.

In languages like JavaScript, immutable and constant may be theoretically the same thing, but in practice "const" means a variable cannot be reassigned, while "immutable" means a value cannot be mutated in place. They are very, very different semantically, because const is always local. Declaring something const has no effect on what happens with the value bound to a const variable anywhere else in the program. Where…

Arrays are a very notable example here. You can append to a const array in JS and TS, even in the same scope it was declared const. That’s always felt very odd to me.

I think JavaScript has a language / terminology problem here. It has to be explained constantly (see) to newcomers that `const a = []` does not imply you cannot say `a.push( x )` (mutation), it just keeps you from being able to say `a = x` further down (re-binding). Since in JavaScript objects always start life as mutable things, but primitives are inherently immutable, `const a = 4` does guarantee `a` will be `4` down the line, though. The same is true of `const a = Object.freeze( [] )` (`a` will always be the empty list), but, lo and behold, you can still add elements to `a` even after `const a = Object.freeze( new Set() )` which is, shall we say, unfortunate.

The vagaries don't end there. NodeJS' `assert` namespace has methods like `equal()`, `strictEqual()`, `deepEqual()`, `deepStrictEqual()`, and `partialDeepStrictEqual()`, which is both excessive and badly named (although there's good justification for what `partialDeepStrictEqual()` does); ideally, `equal()` should be both `strict` and `deep`. That this is also a terminology problem is borne out by explanations that oftentimes do not clearly differentiate between object value and object identity.

In a language with inherent immutability, object value and object identity may (conceptually at least) be conflated, like they are for JavaScript's primitive values. You can always assume that an `'abc'` over here has the same object identity (memory location) as that `'abc'` over there, because it couldn't possibly make a difference were it not the case. The same should be true of an immutable list: for all we know, and all we have to know, two immutable lists could be stored in the same memory when they share the same elements in the same order.

Re: John Carmack on mutable variables

#589

Post by teo_zero »

Razengan wrote: post #145

If designing your hypothetical ideal language, what are some intuitive/cute keywords you would choose for mutables/immutables? `let` is so 2020. `const` is too long. `static` makes me fall asleep at the keyboard. `con` sounds bad. How about `law`? law pi = 3.142 (heh typing on Mac autocompleted this) law c = 29979245 law law = "Dredd" or `set` or `once` or `make`?

Why not "def"?
Post reply on HN