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

461–470 of 663 posts

Re: John Carmack on mutable variables

#461

Post by SpaceNoodled »

jstimpfle wrote: post #210
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…

The immutable approach doesn't conflate the concepts of place, time, and abstract identity, like in-place mutation does. In mutating models, typically abstract (mathematical / conceptual) objects are modeled as memory locations. Which means that object identity implies pointer identity. But that's a problem when different versions of the same object need to be maintained. It's much easier when we represent object ide…

The hardware that these programs are running on store objects in linear memory, so it doesn't not make sense to treat it as such.

Re: John Carmack on mutable variables

#462

Post by DrScientist »

raddan wrote: post #380
DrScientist wrote: post #290

Earlier quoted context omitted.

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?

In functional programs, you very explicitly _do not_ need to understand an entire program. You just need to know that a function does a thing. When you're implementing a function-- sure, you need to know what it does. But you're defining it in such a way that the user should not know _how_ it works, only _what_ it does. This is a major distinction between programs written with mutable state and those written without.…

I think you missed the point. I understand that if you writing a simple function with an expected interface/behaviour then that's all you need to understand. Note this isn't something unique to a functional approach.

However, somebody needs to know how the entire program works - so my question was where does that application state live in a purely functional world of immumutables?

Does it disappear into the call stack?

Re: John Carmack on mutable variables

#464

Post by ajross »

tialaramex wrote: post #441
ajross wrote: post #421

Earlier quoted context omitted.

Seems like you're coming around to my side of the fence that calling these clearly distinct constant expressions "variables" is probably a mistake?

I don't think so? I've been clear that there are three distinct kinds of thing here - constants, immutable variables, and mutable variables. In C the first needs us to step outside the language to the macro pre-processor, the second needs the keyword "const" and the third is the default In Rust the first is a const, the second we can make with let and the third we need let mut, as Carmack says immutable should be the…

There are surely more than three! References can support mutation or not, "constants" may be runtime or compile time.

The point is that the word "variable" inherently reflects change. And choosing it (a-la your malapropism-that-we-all-agree-not-to-notice "immutable variables") to mean something that does (1) is confusing and (2) tends to force us into worse choices[1][2] elsewhere.

A "variable" should reflect the idea of something that can be assigned.

[1] In rust, the idea of something that can change looks like a misspelled dog, and is pronounced so as to imply that it can't speak!

[2] In C++, they threw English out the window and talk about "lvalues" for this idea.

Re: John Carmack on mutable variables

#465

Post by bmitc »

modeless wrote: post #360
bmitc wrote: post #272

Earlier quoted context omitted.

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

His engines are open source, and graphics are far from the only interesting thing about them. If you don't know what he's done that's on you; it's no secret.

So again, what has he done successfully besides C++ graphics?

Re: John Carmack on mutable variables

#466

Post by bmitc »

rvba wrote: post #431
bmitc wrote: post #272

Earlier quoted context omitted.

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…

But he didn't design the Doom game. He designed its graphics engine.

Re: John Carmack on mutable variables

#467

Post by eyelidlessness »

StopDisinfo910 wrote: post #436
eyelidlessness wrote: post #363

Earlier quoted context omitted.

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

But there isn’t anything hilarious about that.

It’s a clear-minded and deliberate approach to reconciling principle with pragmatic utility. We can debate whether it’s the best approach, but it isn’t like… logically inconsistent, surprising, or lacking in self awareness.

Re: John Carmack on mutable variables

#468

Post by DrScientist »

jimbokun wrote: post #387
DrScientist wrote: post #290

Earlier quoted context omitted.

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. Of course not, that's impossible. Modern programs are way to large to keep in your head and reason about. So you need to be able to isolate certain parts of the program and just reason about those pieces while you debug or modify the code. Once you identify the part of the program that needs to change,…

> Once you identify the part of the program that needs to change,

And how do you do that without understanding how the program works at a high level?

I understand the value of clean interfaces and encapsulation - that's not unique to functional approaches - I'm just wondering in the world of pure immutability where the application state goes.

What happens if the change you need to make is at a level higher than a single function?

Re: John Carmack on mutable variables

#469

Post by wtallis »

SpaceNoodled wrote: post #461
jstimpfle wrote: post #210

Earlier quoted context omitted.

The immutable approach doesn't conflate the concepts of place, time, and abstract identity, like in-place mutation does. In mutating models, typically abstract (mathematical / conceptual) objects are modeled as memory locations. Which means that object identity implies pointer identity. But that's a problem when different versions of the same object need to be maintained. It's much easier when we represent object ide…

The hardware that these programs are running on store objects in linear memory, so it doesn't not make sense to treat it as such.

DRAM is linear memory. Caches, less so. Register files really aren't. CPUs spend rather a lot of transistors and power to reconcile the reality of how they manipulate data within the core against the external model of RAM in a flat linear address space.
Post reply on HN