Top
Best
New

Posted by azhenley 3 days ago

John Carmack on mutable variables(twitter.com)
505 points | 607 commentspage 3
markstos 2 days ago|
"State is the enemy".

Every new state is an additional condition to check. A mutated variable implies an additional state to test.

One boolean means two states to test. Four booleans that interact is 2^4 (16) states to test.

baruchel 2 days ago|
Which is why functional programmers believe in the separation of Church and state. https://wiki.c2.com/?SeparationOfChurchAndState
acdbddh 3 days ago||
In python its common to see code like this:

  df = pd.concat(df,other_df)
  df = df.select(...)
  ...
My eyes hurts, when I see it. It makes me avoid python. I bet the reason for this mutable code is a missing simple pipes syntax. I love pipes. In R can do:

  df |> 
    rbind(other_df) |> 
    select(...)
It feels much better.
leviathan 3 days ago||
My eyes would hurt more if I had to look all day at the vertical misalignment of that |> operator
kec 3 days ago||
You could always switch to a better font like Fira Code which has a ligature for this.
adregan 2 days ago||
The gp's comment wasn't made regarding the look of the operator in its ascii representation `|>` but about the vertical misalignment.

Typically you align a pipeline like so:

     df
     |> rbind(other_df)
     |> select(...)
But these topics are largely left to code formatters these days.
kec 2 days ago||
Weird, I have always aligned as the gp showed. I’m reasonably sure tidyverse documentation does the same (which is probably where we both picked it up from).
cubefox 3 days ago|||
Wouldn't that be simply:

  df = pd.concat(df,other_df).select(...)
mr_luc 3 days ago|||
Elixir too (Explorer library; default backend is Pola.rs based)

- https://github.com/elixir-explorer/explorer - https://hexdocs.pm/explorer/Explorer.html

fermisea 3 days ago|||
pandas has a .pipe operator which works exactly like this
zenlot 2 days ago||
Nah, it doesn't. Although you can do similar in Elixir.
shermantanktop 3 days ago||
Const/final by default - preach it, brother, amen and hallelujah. Mutability by default is the rule in the big languages and the world would be a better place if it weren’t.
shmerl 3 days ago||
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.
NathanaelRea 3 days ago||
They could just add a "use immutable;" directive that you place at the top of your file.
Pxtl 3 days ago||
C# does this with the null hole. I wish more languages would take a versioning approach to defaults at the file-level.
JonChesterfield 3 days ago|||
Could be a compiler flag. -const-by-default. Would probably mean you need to scatter mutable across the codebase to get it to compile, but I expect some people would like to have every local annotated as const or mutable.
_flux 3 days ago|||
Maybe the new C++ profiles that are supposedly going to make C++ a safe language could do it.
loeg 3 days ago||
cpp2/cfront could plausibly do this, right? Except he doesn't want to:

https://github.com/hsutter/cppfront/wiki/Design-note%3A-cons...

shmerl 3 days ago||
Well, if they are willing to break backwards compatibility, a lot of things can be improved, including this.
storus 3 days ago||
I had enormous fun optimizng C++ via self-modifying assembly to squeeze the utmost performance of some critical algorithms, and now this drive towards immutable everything feels like cutting my hands and legs off and forcing me to do subpar engineering.
no_wizard 3 days ago||
Compiler optimizations make up for it, usually. Thats been my experience at least.

An important thing to keep in mind is just how far compilers have come over the least 40 years. Often, with immutable languages, they can do extremely efficient compile only optimizations because of said guaranteed immutability by default.

Its not true in every case, of course, but I think for most situations compilers do a more than good enough job with this.

ryandrake 3 days ago||
Same here, I grew up in a world where you had a handful of registers and a bunch of memory locations, and those were your variables.

                clc
                lda value
                adc #1
                sta value
                lda value+1
                adc #0
                sta value+1

    value       .byte 0,0
These constraints are pretty much built into my concept of programming and it would take great effort to break out of it. It feels nice doing:

    x = 20
    x = x + func(y)
    x = x / func(z)
And it would feel weirdly wasteful to do:

    x = 20
    x1 = x + func(y)
    x2 = x1 / func(z)
Like, I know that variables are no longer a scarce resource, but my brain still wants to conserve them.
1718627440 3 days ago||
To me this also seem to be wasteful, even if not for the computer, but it wastes my amount of working state I can keep in my head, which is very limited.
restalis 2 days ago||
I was thinking about this too. When you read a program, there is this information payload, which is the metaphorical ball you have to keep your eyes on, and more or less forget about the rest as soon as it isn't relevant any more. In the functional paradigm it's like seeing the juggle of a bunch of such balls instead (plus the expectation to admire it), but that's just wasteful on reader's attention.
garrison 1 day ago||
This reminds me of an earlier blog post by the same author: https://web.archive.org/web/20121111234839/http://www.altdev...
waffletower 2 days ago||
Would be beneficial if Rich Hickey's opinion and experience regarding mutable state was given more weight than John Carmack's.
loeg 3 days ago||
Yeah, I also wish it was the default. But it's a little too verbose to just sprinkle on every variable in C++. Alas. Rust gets this right, but I'm stuck with C++ at work.
veltas 3 days ago||
100%, life's too short.

Ultra-pedantic const-correctness (vs tasteful const-correctness on e.g. pass-by-reference arguments or static/big objects) catches nearly no bugs in practice and significantly increases the visual noise of your code.

If you have luxury of designing a new language or using one with default mutability then do so, but don't turn C coding styles into C++-envy, or C++ coding styles into Rust-envy.

maleldil 3 days ago||
> But it's a little too verbose to just sprinkle on every variable in C++

It's worth it, though. Every variable that isn't mutated should be const. Every parameter not mutated should be const, and so should every method that doesn't mutate any fields. The mutable keyword should be banned.

loeg 2 days ago||
Const annotations are worth it for methods and APIs, but not most local variables.
maleldil 2 days ago||
I'd argue that it is. Use const by default, so it's obvious to the reader if something is mutated or not. It's easier to read code when you don't have to worry about how values may change over time. This is why Rust made the right choice.
loeg 1 day ago||
Yeah, I think it's a great default, and Rust got that right. It's just too noisy in C++ as the non-default.
DonHopkins 3 days ago||
Did you ever have one of those days when variables won't and constants aren't?
Razengan 3 days ago|
If designing your hypothetical ideal language, what are some intuitive/cute keywords you would choose for mutables/immutables?

`let` is so 2020. `const` is too long. `static` makes me fall asleep at the keyboard. `con` sounds bad. How about

`law`?

    law pi = 3.142 (heh typing on Mac autocompleted this)

    law c = 29979245

    law law = "Dredd"
or `set` or `once` or `make`?
tomaytotomato 3 days ago||
There was a proposal in Java a few years back to introduce "val".

I think it never gained traction but it would have been nice to have this in Java

    val firstName = "Bob";
    val lastName = "Tables";
    var fullName = "";

    fullName = firstName + " " + lastName;
Razengan 3 days ago|||
That's an aesthetically awkward and also bug-prone syntax: So just a difference of 1 single letter (that looks similar) to mean the completely opposite thing?? Nah you don't want that, and I don't either.
nvlled 3 days ago|||
Kotlin uses var/val too[0] which is what Java is trying to copy. I have never written any kotlin code before, so I don't know if this would be a problem in practice. On the plus side, var and val both have the same length, so the variable declaractions are properly aligned. The names are also intuitive as far as I can tell.In theory, I'd probably be okay with it.

[0] https://kotlinlang.org/docs/basic-syntax.html#variables

ahoka 3 days ago||
Not a problem in practice as you use val 99.99% percent of the cases (which shows why immutability should be the default, because most often that is needed) and Idea underlines any mutable references, so the sticks out. It also suggests val when a var is not actually mutated.
dionian 3 days ago|||
They're intuitively named. A value is a value. A variable is a variable.
Razengan 3 days ago||
A variable is also a value.
mcdeltat 3 days ago|||
Wouldn't this "val" be the same as "final"?

Also related, it annoys me that Java has final but otherwise poor/leaky support for immutability. You can mark something final but most Java code (and a lot of the standard library) uses mutable objects so the final does basically nothing... C++ "const" desparately needs to spread to other languages.

veltas 3 days ago|||
What is wrong with let?
Razengan 3 days ago||
Nothing, it's just been done, just trying to think of some better/newer ways to say it :)
teo_zero 2 days ago||
Why not "def"?
Razengan 2 days ago||
That's fine. But couldn't that just mean "define" any value at all?

There's nothing in it to say it's specifically for defining a value only ONCE.

More comments...