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

431–440 of 663 posts

Re: John Carmack on mutable variables

#431

Post by rvba »

bmitc wrote: post #272
lopatin wrote: post #12

How fast this got to the top, you would think John Carmack just invented nuclear fusion.

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

Doom which was countless fun for people up to this day who make mods? (E.g. the great Myhouse.wad that was perhaps FPS of the year... 2023)

Quake, which was a good game, but arguably a better engine that lead to things like Half-Life 1?

Other games?

Shared the code to Doom and Quake?

I guess you dont understand how big of a game Doom was. The first episode holds suprisngly well up to this day, even after hundreds of doom-clones as they used to call FPS games.

Re: John Carmack on mutable variables

#432

Post by fnordsensei »

ghurtado wrote: post #402
veilrap wrote: post #382

Earlier quoted context omitted.

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

That’s the point, you’re just haggling about scopes now. All the way from being new per program invocation to new per loop.

Immutability doesn’t have this connotation.

Re: John Carmack on mutable variables

#433

Post by Warwolt »

anymouse123456 wrote: post #283

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

It's a variable simply because it doesn't refer to a specific object, but any object assigned to it as either function argument or by result of a computation.

It's in fact us programmers who are the odd ones out compared to how the word variable has been used by mathematics and logicians for a long time

Re: John Carmack on mutable variables

#434

Post by scott_w »

DrScientist wrote: post #290
emil0r wrote: post #185

Earlier quoted context omitted.

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…

Sure modularity, encapsulation etc are great tools for making components understandable and maintainable. However, don't you still need to understand the entire program as ultimately that's what you are trying to build. And if the state of the entire programme doesn't change - then nothing has happened. ie there still has to be mutable state somewhere - so where is it moved to?

> However, don't you still need to understand the entire program as ultimately that's what you are trying to build.

Depends on what I'm trying to do. If what I'm trying to handle is local to the code, then possibly not. If the issue is what's going into the function, or what the return value is doing, then I likely do need that wider context.

What pure-functional functions do allow is certainty the only things that can change the behaviour of that function are the inputs to that function.

Re: John Carmack on mutable variables

#435

Post by shagie »

throwaway2037 wrote: post #113
hyperhello wrote: post #3

> I wish it was the default, and mutable was a keyword. I wish the IDE would simply provide a small clue, visible but graphically unobtrusive, that it was mutated . In fact, I end up wishing this about almost every language feature that passes my mind. For example, I don't need to choose whether I can or can't append to a list; just make it unappendable if you can prove I don't append. I don't care if it's a map, lis…

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 The variable 'def' is underlined. Mouse-over hint shows: 'Reassigned local variable'. To be clear, 'abc' is not underlined. When I write Java, I try to use the smallest variable scopes possible with as much final (keyword) as possible. It helps me to write more maintaina…

As an aside, you might also enjoy the inline inferred annotations.

https://www.jetbrains.com/help/idea/annotating-source-code.h...

Seeing @NotNull in there even if the author hasn't specifically written that can help in understanding (and not needing to consider) various branches.

Re: John Carmack on mutable variables

#436

Post by StopDisinfo910 »

eyelidlessness wrote: post #363
StopDisinfo910 wrote: post #327

Earlier quoted context omitted.

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

> Sometimes they even fail to even realise that it's what they are doing. Because that’s not what they’re doing. They’re isolating state in a systemic, predictable way.

Lenses is mutation by another name. You are basically recreating states on top of an immutable system. Sure, it's all immutable actually but conceptually it doesn't really change anything. That's what makes it hilarious.

In the end, the world is stateful and even the purest abstractions have to hit the road at some point. But the authors of Haskell were fully aware of that. The monadic type system was conceived as a way to easily track side effects after all, not banish them.

Re: John Carmack on mutable variables

#437

Post by mtlmtlmtlmtl »

It's fascinating how even when Carmack says something rather obvious and unoriginal, that many people have said before, sometimes decades ago, it still spawns a 400+ comment thread on HN. I really don't get it, it's almost like a cult of personality at this point.

Re: John Carmack on mutable variables

#438

Post by kins »

mtlmtlmtlmtl wrote: post #437

It's fascinating how even when Carmack says something rather obvious and unoriginal, that many people have said before, sometimes decades ago, it still spawns a 400+ comment thread on HN. I really don't get it, it's almost like a cult of personality at this point.

It always was.

Re: John Carmack on mutable variables

#439

Post by munificent »

skeezyjefferson wrote: post #205
rendaw wrote: post #188

Earlier quoted context omitted.

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

whats the difference between immutable and constant, which has been in use far longer? why are you calling it mutable?

"Constant" is ambiguous. Depending on who you ask, it can mean either:

1. A property known at compile time.

2. A property that can't change after being initially computed.

Many of the benefits of immutability accrue properties whose values are only known at runtime but which are still known to not change after that point.

Re: John Carmack on mutable variables

#440

Post by ColeShepherd »

QuadrupleA wrote: post #367

Love Carmack, but hard disagree on this and a lot of similar functional programming dogma. I find this type of thing very helpful: classList = ['highlighted', 'primary'] if discount: classList.append('on-sale') classList = ' '.join(classList) And not having to think about e.g. `const` vs `let` frees up needless cognitive load, which is why I think python (rightly) chose to not make it an option.

Some potential alternatives to consider:

1.

    classList = ['highlighted', 'primary']
        .concatif(discount, 'on-sale')
        .join(' ')
2.

    classList = ' '.join(['highlighted', 'primary'] + (['on-sale'] if discount else []))
3.

    mut classList = ['highlighted', 'primary']
    if discount:
        classList.append('on-sale')
    classList = ' '.join(classList)

    freeze classList
4.

    def get_class_list(discount):
        mut classList = ['highlighted', 'primary']
        if discount:
            classList.append('on-sale')
        classList = ' '.join(classList)
        return classList

    classList = get_class_list(discount)
Post reply on HN