But this feature (preventing mutation of mutable structures recursively) is uncommon. So far I’ve seen it only in PHP and Rust. What other languages has it too?
recursive mutation is not even the issue, const in JavaScript just means “I will not reassign this reference” so even the top-level value is mutable. You can const a=[]; a.push({});
If top-level mutation prevention can be implemented, then all levels down is not that hard, I think. But I can’t imagine how to do it in languages with pass-everything-by-reference semantics, and most languages have such semantics (js, java, python, ruby, etc).
Some of such languages has “constant binding” feature too, i.e. java’s final, which lots of users find useless, and still I see lots of final in java code. Clojure has let which is similar to having only const in js, and it also can’t prevent mutation of underlying objects:
=> (let [a (java.util.LinkedList.)] (.add a "foo") a)
("foo")
So while mutation by calling methods can’t be prevented at all in js, and it’s not surprising behavior, mutation of captured var bindings can be prevented and I think it’s useful. Lots of gotchas in js happen when closures accidentally mutate captured vars (or when captured environment mutate them).
Languages with multiple passing semantics such as PHP, which have by-value and by-reference passed function args, or Rust which have & and &mut, can have mutation prevention. In Rust you can see if object method does not mutate object if it has &self and not &mut self, for example. BTW, I written lots of PHP code and still don’t understand its semantics, it’s feels on the same level of complexity as Rust.
Its not so much about whether you can have an immutable structure, it’s whether you think you can.
Before PHP’s const or define() supported e.g. constant arrays, you couldn’t assign them - it would error at compile time (which is effectively runtime for php).
It’s not uncommon for things with undesirable qualities to emerge as the dominant entity in their domain. The flaws of JavaScript should not be assumed to correlate with its rate of adoption, whether or not they should.
Do you laugh because despite all of this Javascript is arguably actuslly taking over (for whatever that means), while PHP, with its real consts, is slowly fading away?
would this be the same javascript community that was just recently ass fucked in public because they needed a third party module to pad strings, or the one that needed a third party module to determine if a number is even?
I use php but I’m not attached to it. I also write shell regularly and I’ve used some
Lua, a bit of java even. I’d like to try D soon.
Even then I’ll use php or shell or lua or whatever where it’s appropriate.
The javascript community has no such concept. That’s why you end up with ridiculous nodejs “alternatives” for things that could be achieved out of the box with a little shell on most *nix systems.
I think the pushback is valid but I still like the idea that by default values shouldn’t change. If you want real immutability, we’re stuck with the library options which actually work great, but I think there’s no harm in “overuse” of const, other than it seems to annoy the op, and others.
The author does claim that there is harm in the overuse of const. His argument is in Section 5 and basically says that when you use const for things that happen to be immutable, instead of things that are intended to be immutable, then you’re loosing the potential communication benefits from const.
I think the author would agree that default values shouldn’t change, but const doesn’t guarantee immutability, just not reassignment.
The authors argument here, though, is basically “We all know what const means but it doesn’t mean what I think it should do”. I don’t know of any JS engineers who use const and are confused that it doesn’t guarantee the immutability of every aspect of the variable. I do agree that emphasis on const is overrated.
I actually have more time for the unmade argument that there’s too much focus on “this should be const” rather than “does this need to be let, can we find a way to not do that?”
At least const prevents mutating binding when variable is captured by closures. You’ll get “TypeError: Assignment to constant variable.” if you try to rebind it inside closure. Mutable variables captured by closures are common gotcha in js: this is why let is added to language too (var is hoisted to function level, causing confusion).
This seems a lot like Object.freeze(obj) / deepFreeze. Seems like let is the new var, const is the new var .. = Object.freeze(..) or deepFreeze variant. Except const doesn’t even do that. Hmm
If all variables are const except those that are reassigned, let becomes a strong signal to expect the reassignment. I don’t see a difference between assignments that “should” never change and assignments that “just happen to never change”. From the perspective of someone reading/debugging code, the question is simply “did the assignment change?” If I use const everywhere, this question can be quickly and confidantly answered. If I use let for assignments that don’t actually change, then I lose the certainty that let signals a reassignment somewhere further in the execution.
“Const isn’t useful because the assigned value is still mutable” is a confusion about the semantics of const. Mutability and side effects create many traps. Mutable assignment is one trap. Mutable values is a second trap. Strict use of const and let is an escape from the first trap. The author must look somewhere else for an escape from the second trap. In general, s/he might be better served by a compile-to-JavaScript language.
Things like this are why I laugh whenever people claim javascript is “taking over”.
Even fucking php has const’s that are actually constant.
Honestly the only people that believe JavaScript is taking over are people who haven’t used anything else.
And yet it’s everywhere. If any language is really “taking over”, it’s JS. It’s mandatory in the browser, and it’s optional almost everywhere else.
That’s why it’s so big. If you want to learn only one language it has to be JS.
You think javascript is mandatory to make a website or web app?
But this feature (preventing mutation of mutable structures recursively) is uncommon. So far I’ve seen it only in PHP and Rust. What other languages has it too?
recursive mutation is not even the issue, const in JavaScript just means “I will not reassign this reference” so even the top-level value is mutable. You can
const a=[]; a.push({});If top-level mutation prevention can be implemented, then all levels down is not that hard, I think. But I can’t imagine how to do it in languages with pass-everything-by-reference semantics, and most languages have such semantics (js, java, python, ruby, etc).
Some of such languages has “constant binding” feature too, i.e. java’s
final, which lots of users find useless, and still I see lots offinalin java code. Clojure hasletwhich is similar to having onlyconstin js, and it also can’t prevent mutation of underlying objects:So while mutation by calling methods can’t be prevented at all in js, and it’s not surprising behavior, mutation of captured var bindings can be prevented and I think it’s useful. Lots of gotchas in js happen when closures accidentally mutate captured vars (or when captured environment mutate them).
Languages with multiple passing semantics such as PHP, which have by-value and by-reference passed function args, or Rust which have
&and&mut, can have mutation prevention. In Rust you can see if object method does not mutate object if it has&selfand not&mut self, for example. BTW, I written lots of PHP code and still don’t understand its semantics, it’s feels on the same level of complexity as Rust.Its not so much about whether you can have an immutable structure, it’s whether you think you can.
Before PHP’s
constordefine()supported e.g. constant arrays, you couldn’t assign them - it would error at compile time (which is effectively runtime for php).It’s not uncommon for things with undesirable qualities to emerge as the dominant entity in their domain. The flaws of JavaScript should not be assumed to correlate with its rate of adoption, whether or not they should.
Do you laugh because despite all of this Javascript is arguably actuslly taking over (for whatever that means), while PHP, with its real consts, is slowly fading away?
would this be the same javascript community that was just recently ass fucked in public because they needed a third party module to pad strings, or the one that needed a third party module to determine if a number is even?
I use php but I’m not attached to it. I also write shell regularly and I’ve used some Lua, a bit of java even. I’d like to try D soon.
Even then I’ll use php or shell or lua or whatever where it’s appropriate.
The javascript community has no such concept. That’s why you end up with ridiculous nodejs “alternatives” for things that could be achieved out of the box with a little shell on most *nix systems.
I think the pushback is valid but I still like the idea that by default values shouldn’t change. If you want real immutability, we’re stuck with the library options which actually work great, but I think there’s no harm in “overuse” of const, other than it seems to annoy the op, and others.
The author does claim that there is harm in the overuse of const. His argument is in Section 5 and basically says that when you use const for things that happen to be immutable, instead of things that are intended to be immutable, then you’re loosing the potential communication benefits from const.
I think the author would agree that default values shouldn’t change, but const doesn’t guarantee immutability, just not reassignment.
The authors argument here, though, is basically “We all know what const means but it doesn’t mean what I think it should do”. I don’t know of any JS engineers who use const and are confused that it doesn’t guarantee the immutability of every aspect of the variable. I do agree that emphasis on const is overrated.
I actually have more time for the unmade argument that there’s too much focus on “this should be const” rather than “does this need to be let, can we find a way to not do that?”
At least
constprevents mutating binding when variable is captured by closures. You’ll get “TypeError: Assignment to constant variable.” if you try to rebind it inside closure. Mutable variables captured by closures are common gotcha in js: this is whyletis added to language too (varis hoisted to function level, causing confusion).This seems a lot like Object.freeze(obj) / deepFreeze. Seems like
letis the newvar,constis the newvar .. = Object.freeze(..)or deepFreeze variant. Except const doesn’t even do that. HmmIf all variables are const except those that are reassigned, let becomes a strong signal to expect the reassignment. I don’t see a difference between assignments that “should” never change and assignments that “just happen to never change”. From the perspective of someone reading/debugging code, the question is simply “did the assignment change?” If I use const everywhere, this question can be quickly and confidantly answered. If I use let for assignments that don’t actually change, then I lose the certainty that let signals a reassignment somewhere further in the execution.
“Const isn’t useful because the assigned value is still mutable” is a confusion about the semantics of const. Mutability and side effects create many traps. Mutable assignment is one trap. Mutable values is a second trap. Strict use of const and let is an escape from the first trap. The author must look somewhere else for an escape from the second trap. In general, s/he might be better served by a compile-to-JavaScript language.