Live data from Hacker News

John Carmack on mutable variables

twitter.com

71–80 of 663 posts

Re: John Carmack on mutable variables

#71
Constants are useful for reasoning about code, but anyone who focuses only on making everything an immutable is missing the point. The main goal should be achieving referential transparancy.

It can be perfectly fine to use mutable variables within a block, like a function when absolutely needed - for example, in JavaScript's try catch and switch statements that need to set a variable for later use. As long as these assignments are local to that block, the larger code remains side-effect free and still easy to reason about, refactor and mantain.

https://rockthejvm.com/articles/what-is-referential-transpar...

Re: John Carmack on mutable variables

#72
post #60
post #30

Earlier quoted context omitted.

Rust is not very suitable for functional programming because it is aggressively non-garbage-collected. Any time Rustaceans want to do the kind of immutable DAG thing that gives functional languages so much power, they seem to end up either taking the huge performance and concurrency hit of fine-grained reference counting, or they just stick all their nodes in a big array.

Using a big array has good performance though?

Computer memory is already a big array. Probably what you are thinking of is that processing array items sequentially is a lot faster than following pointers, but in the cases I'm talking about, you end up using array indices instead of pointers, which isn't much faster.

Re: John Carmack on mutable variables

#74

Earlier quoted context omitted.

Technically you could just use an assignment ternary expression for this: const y = (x === true) ? true : false; I used this kind of style for argument initialization when I was writing JS code, right at the top of my function bodies, due to ES not being able to specify real nullable default values. (and I'm setting apart why I think undefined as a value is pointless legacy). Composite.prototype.SetPosition(x, y, z)…

I typically only use ternaries for single operations and extract to a function if it's too big. Although they are quite fun in JSX. For your code i'd probably do: function SetPosition(x, y, z) { if (!(isNumber(x) && isNumber(y) && isNumber(z))) { // Default vals return; } x = clamp(x, 0, 1337); y = clamp(y, 0, 1337); z = z; }

I always call this the difference of return branch styles. Yours I'd describe as "fast fail" aka return false as quickly as possible (for lack of a better terminology) whereas I personally prefer to have a single return false case at the bottom of my function body, and the other validation errors (e.g. in Go) are usually in the else blocks.

In JS, errors are pretty painful due to try/catch, that's why I would probably these days recommend to use Effect [1] or similar libraries to have a failsafe workflow with error cases.

Errors in general are pretty painful in all languages in my opinion. The only language where I thought "oh this might be nice" was Koka, where it's designed around Effect Types and Handlers [2]

[1] https://effect.website/

[2] https://koka-lang.github.io/koka/doc/index.html

Re: John Carmack on mutable variables

#76
post #7
post #2

> Making almost every variable const at initialization is good practice. I wish it was the default, and mutable was a keyword. It's funny how functional programming is slowly becoming the best practice for modern code (pure functions, no side-effects), yet functional programming languages are still considered fringe tech for some reason. If you want a language where const is the default and mutable is a keyword, try…

> If you want a language where const is the default and mutable is a keyword, try F# for starters. I switched and never looked back. Rust is also like this (let x = 5; / let mut x = 5;). Or you can also use javascript, typescript and zig like this. Just default to declaring variables with const instead of let / var. Or swift, which has let (const) vs var (mutable). FP got there first, but you don't need to use F# to…

Are there languages that automatically extend this to things like data structure members? One of the things I like about the C++ const keyword is that if you declare an instance of a struct/class as const it extends that to its members. If the instance isn’t const, you can still mutate them (as long as they aren’t declared const within the structure itself)

Re: John Carmack on mutable variables

#78

Earlier quoted context omitted.

You could do an absolutely disgusting IIFE if you need the curly brace spice in your life, instead of a typical JS ternary. const y = (() => { if (x) { return true; } else { return false; })();

Technically you could just use an assignment ternary expression for this: const y = (x === true) ? true : false; I used this kind of style for argument initialization when I was writing JS code, right at the top of my function bodies, due to ES not being able to specify real nullable default values. (and I'm setting apart why I think undefined as a value is pointless legacy). Composite.prototype.SetPosition(x, y, z)…

nitpick: cleaner w/o ()'s, as '=' is the 2nd lowest operator, after the comma separation operator.

Re: John Carmack on mutable variables

#79
post #32
post #26

Earlier quoted context omitted.

> come with the baggage of foreign looking syntax Maybe they're right about the syntax too though? :)

Which one, Erlang, Lisp, or ML?

Honestly I find ML derived languages the most pleasant to look at.

Re: John Carmack on mutable variables

#80
post #2

> Making almost every variable const at initialization is good practice. I wish it was the default, and mutable was a keyword. It's funny how functional programming is slowly becoming the best practice for modern code (pure functions, no side-effects), yet functional programming languages are still considered fringe tech for some reason. If you want a language where const is the default and mutable is a keyword, try…

Pure functional works great until it doesn't. For a lot of systems-y and performance-oriented code you need the escape hatches or you'll be in for a lot of pain and annoyance. As a practical observation, I think it was easier to close this gap by adding substantial functional capabilities to imperative languages than the other way around. Historically, functional language communities were much more precious about the…

Unfortunately unless there's an explicit way to state what has side effects like a mut keyword, a lot of fp programming advantages lose value because most devs default to mutable stuff, so the fp benefits don't compound
Post reply on HN