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

401–410 of 663 posts

Re: John Carmack on mutable variables

#401

Post by jimbokun »

nixpulvis wrote: post #282

I 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…

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.

Re: John Carmack on mutable variables

#402

Post by ghurtado »

veilrap wrote: post #382
skeezyjefferson wrote: post #368

Earlier quoted context omitted.

> As in - it's not very "constant" if you keep re-making it in your loop, right? you cant change a constant though

He’s implying that the variable it’s being defined within the loop. So, constant, but repeatedly redefined.

That's the opposite of what any reasonable engineer means by "constant".

Re: John Carmack on mutable variables

#403

Post by dwwoelfel »

EastLondonCoder wrote: post #128

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

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)]
    ...)
He mentions that C and C++ allow const variables, but Clojure doesn't support that.

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

Re: John Carmack on mutable variables

#404

Post by Bayko »

riskable wrote: post #388
nailer wrote: post #336

Earlier quoted context omitted.

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

It also doesn't make sense for `process()` to be an attribute of `result`. Why would you instantiate a class and call it result‽

A more common example for me at work is getting a response from url. Then you gotta process it further like response.json() or response.header or response.text etc etc. and then again select the necessary array index or doc value from it. Giving a name like pre_result or result_json etc etc would just become cumbersome.

Re: John Carmack on mutable variables

#405

Post by hackthemack »

DougBTX wrote: post #381
hackthemack wrote: post #255

One area that I like to have immutability is in function argument passing. In javascript (and many other languages), I find it weird that arguments in function act differently depending on if they are simple (strings, numbers) versus if they are complex (objects, arrays). 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. I made…

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

I guess in javascript world, the phrasing I am looking for would be

I wish all arguments were copies unless I put some symbol that says, alright, go ahead and give me the original to mutate?

It seems like this way, you reduce side effects, and if you want the speed of just using the originals, you could still do that by using special notation.

Re: John Carmack on mutable variables

#406

Post by maleldil »

considerdevs wrote: post #151

This is the kind of wisdom that comes after hours of debugging and discovering the bug was your own variable reuse. Wouldn't this be an easy task for SCA tool e.g. Pylint? It has atleast warning against variable redefinition: https://pylint.pycqa.org/en/latest/user_guide/messages/refac...

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.

Re: John Carmack on mutable variables

#407

Post by adrianN »

ryandv wrote: post #332
EastLondonCoder wrote: post #216

Earlier quoted context omitted.

I agree that the explicit timeline you get with immutability is certainly helpful, but I also think its much easier to understand the total state of a program. When an imperative program runs you almost always have to reproduce a bug in order to understate the state that caused it, fairly often in Clojure you can actually deduct whats happening.

That's right - immutability enables equational reasoning, where it becomes possible to actually reason through a program just by inspection and evaluation in one's head, since the only context one needs to load is contained within the function itself - not the entire trace, where anything along the thread of execution could factor into your function's output, since anybody can just mutate anybody else's memory willy-…

In theory it’s certainly right that imperative programs are harder to reason about. In practice programmers tend to avoid writing the kind of program where anything can happen.

Re: John Carmack on mutable variables

#408

Post by maleldil »

loeg wrote: post #29

Yeah, I also wish it was the default. But it's a little too verbose to just sprinkle on every variable in C++. Alas. Rust gets this right, but I'm stuck with C++ at work.

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

Re: John Carmack on mutable variables

#410

Post by _flux »

shmerl wrote: post #24

Proposing making immutable by default in C or C++ doesn't make sense due to backwards compatibility reasons. New languages like Rust have easier time making better choices with immutable by default.

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