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

591–600 of 663 posts

Re: John Carmack on mutable variables

#591

Post by zenlot »

tredre3 wrote: post #534
zenlot wrote: post #527

Earlier quoted context omitted.

You understand how games work, do you? Please tell me you do. Else, what kind of argument is it?

The engine enables people with actual creativity to realize their vision. I believe Carmack was part of that creative process, but the condescending tone of your comment really isn't appropriate because in most games the engine is just a means to an end (nobody sane idolizes games because they're using unreal underneath, for example)..

Just decided to talk shit on Friday? What you believe doesn't matter. Facts matter, and your knowledge of facts are far away from truth.

Re: John Carmack on mutable variables

#593

Post by 1718627440 »

AaronAPU wrote: post #442
furyofantares wrote: post #374

Earlier quoted context omitted.

Fair enough re: "outrageous"! It's actually math heavy code (or maybe medium heavy?) where I really like naming every intermediate. fov, tan_fov, half_tan_fov, center_x, norm_x

I spent a decade or so working on video codecs with an international team, and there was sort of an unwritten rule that code shouldn’t have comments and variable names shouldn’t be descriptive (english language couldn’t be assumed). Which sounds really awful, but after a while it forces you to parse the logic itself instead of being guided by possibly-out-of-date comments and variable names. I now prefer less verbosi…

This is kind of the opposite of LLMs, they seem to derive meaning mostly from the variable names, not from what the code actually does.

Re: John Carmack on mutable variables

#594

Post by ErroneousBosh »

jimbokun wrote: post #585
ErroneousBosh wrote: post #563

Earlier quoted context omitted.

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

Well, the stuff I'm writing is in C, but in general it would make no sense for anything to attempt to add items to a fixed-sized buffer.

If you have something so fundamentally broken as to attempt that, you'd probably want to look at mutexes.

Why one earth would you have something attempt to expand a fixed-sized buffer while something else is working on it?

Re: John Carmack on mutable variables

#595

Post by jstimpfle »

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.

Can you clarify?

Re: John Carmack on mutable variables

#596

Post by lock1 »

smrq wrote: post #554
tmtvl wrote: post #521

Earlier quoted context omitted.

Calling tau 2pi is the most cursed thing I've seen all day. Appropriate for Halloween.

If you call a variable tau in production code then you're being overly cute. I know what it means, because I watch math YouTube for fun, but $future_maintainer in all likelihood won't.

Where do you draw the line then? Stopping at `tau` just because `$future_maintainer` might get confused feels like an arbitrary limit to me.

What about something like `gamma`? Lorentz factor? Luminance multiplier? Factorial generalization?

Why not just use the full sentence rather than assign it to an arbitrary name/symbol `gamma` and leave it dependent on the context?

And it's not that hard to add an inline comment to dispel the confusion

  const tau = 2*pi; // Alternate name for 2pi is "tau"

Re: John Carmack on mutable variables

#597

Post by StopDisinfo910 »

eyelidlessness wrote: post #467
StopDisinfo910 wrote: post #436

Earlier quoted context omitted.

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.

You don’t see what’s hilarious about recreating what you are pretending to remove only one abstraction level removed?

Anyway, I have great hopes for effect system as a way to approach this in a principled way. I really like what Ocaml is currently doing with concurrency. It’s clear to me that there is great value to unlock here.

Re: John Carmack on mutable variables

#598

Post by runeks »

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.

One big problem with mutation is that it makes it too easy to violate many good design principles, e.g. modularity, encapsulation and separation of concerns.

Because any piece of code that holds a reference to a mutable variable is able to, at a distance, modify the behavior of a piece of code that uses this mutable variable.

Conversely, a piece of code that only uses immutable variables, and takes as argument the values that may need to vary between executions, is isolated against having its behavior changed at a distance at any time.

Re: John Carmack on mutable variables

#599

Post by DemocracyFTW2 »

zelphirkalt wrote: post #230
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.

Made a similar experience with Scheme. I could tell people whatever I wanted, they wouldn't really realize how much cleaner and easier to test things could be, if we just used functions instead of mutating things around. And since I was the only one who had done projects in an FP language, and they only used non-FP languages like Java, Python, JavaScript and TypeScript before, they would continue to write things base…

I'm really afraid that the weak point of the argument is really Scheme having a Lisp syntax. One might say syntax is the most superficial thing about a language but as a matter of fact it's the mud pool in front of the property where everybody's wheels get stuck and they feel their only option is to go into reverse and maybe try another day, or never. The same happens with APL; sure it's a genius who invented it and tic-tac-toe in a single short line of code is cool—doesn't mean many people get over the syntax.

FWIW I believe that JS for one would greatly benefit from much better support for immutable data, including time- and space-efficient ways to produce modified copies of structured data (like you don't think twice when you do `string.replace(...)` where you do in fact produce a copy; `list.push(...)` could conceivable operate similarly).

Re: John Carmack on mutable variables

#600

Post by nvarsj »

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.

> I think it may be one of those things you have to see in order to understand.

Or the person doesn't understand, then declares the language to be too difficult to use. This probably happens more than the former, sadly.

ex. I've heard people argue for rewriting perfectly working Erlang services in C++ or Java, because they find Erlang "too difficult". Despite it being a simpler language than either of those.

Post reply on HN