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.
They could just add a "use immutable;" directive that you place at the top of your file.
John Carmack on mutable variables
61–70 of 663 posts
Re: John Carmack on mutable variables
#62In JavaScript, I really like const and have adopted this approach. There are some annoying situations where it doesn't work though, to do with scoping. Particularly: - if (x) { const y = true } else { const y = false } // y doesn't exist after the block - try { const x = foo } catch (e) { } // x doesn't exist after the try block
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; })();
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) {
x = (isNumber(x) && x >= 0 && x = 0 && y Re: John Carmack on mutable variables
#63> 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…
For some reason, this makes me think of SVG's foreignObject tag that gives a well-defined way to add elements into an SVG document from an arbitrary XML namespace. Display a customer invoice in there, or maybe a Wayland protocol. The sky's the limit!
On the other hand, HTML had so many loose SVG tags scattered around the web that browsers made a special case in the parser to cover them without needing a namespace.
And we all know how that played out.
Posted from an xhtml foreignObject on my SVGphone
Re: John Carmack on mutable variables
#64In JavaScript, I really like const and have adopted this approach. There are some annoying situations where it doesn't work though, to do with scoping. Particularly: - if (x) { const y = true } else { const y = false } // y doesn't exist after the block - try { const x = foo } catch (e) { } // x doesn't exist after the try block
const y = x ? true : false;
Re: John Carmack on mutable variables
#65In JavaScript, I really like const and have adopted this approach. There are some annoying situations where it doesn't work though, to do with scoping. Particularly: - if (x) { const y = true } else { const y = false } // y doesn't exist after the block - try { const x = foo } catch (e) { } // x doesn't exist after the try block
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; })();
Re: John Carmack on mutable variables
#66Immutability was gaining huge traction with Java... then large parts of the industry switched to golang and we hardly make anything immutable.
Re: John Carmack on mutable variables
#67In JavaScript, I really like const and have adopted this approach. There are some annoying situations where it doesn't work though, to do with scoping. Particularly: - if (x) { const y = true } else { const y = false } // y doesn't exist after the block - try { const x = foo } catch (e) { } // x doesn't exist after the try block
val result = if (condition) { val x = foo() y = bar(x) y + k // return of last expression is return value of block } else { baz() }
Or:
val q = try { a / b } catch (e: ArithmeticException) { println("Division by zero!") 0 // Returns 0 if an exception occurs }
Edit: ugh, can't get the formatting to work /facepalm.
Re: John Carmack on mutable variables
#68[flagged]
Re: John Carmack on mutable variables
#69In JavaScript, I really like const and have adopted this approach. There are some annoying situations where it doesn't work though, to do with scoping. Particularly: - if (x) { const y = true } else { const y = false } // y doesn't exist after the block - try { const x = foo } catch (e) { } // x doesn't exist after the try block
Why not do: const y = x ? true : false;
Re: John Carmack on mutable variables
#70Earlier 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)…
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;
}