4 ms·

whats the difference between immutable and constant, which has been in use far longer? why are you calling it mutable?

Thorrez 1y ago
Immutable and constant are the same. rendaw didn't use the word mutable. One reason someone might use the word "mutable" is that it's a succinct way of expressing an idea. Alternative ways of expressing the same idea are longer words (changeable, non-constant).
- kgwxd 1y ago
  They aren't the same for object references. The reference can't be changed, but the properties can.
  - Thorrez 1y ago
    Depends on the language. In C++ const std::vector<int>& foo = bar.GetVector(); foo is a constant object reference cannot have its properties changed (and also cannot be changed to refer to a new object). std::vector<int>& foo = bar.GetVector(); Is an object reference that can have its properties changed (but cannot be changed to refer to a new object).
- a4isms 1y ago
  In languages like JavaScript, immutable and constant may be theoretically the same thing, but in practice "const" means a variable cannot be reassigned, while "immutable" means a value cannot be mutated in place. They are very, very different semantically, because const is always local. Declaring something const has no effect on what happens with the value bound to a const variable anywhere else in the program. Whereas, immutability is a global property: An immutable array, for example, can be passed around and it will always be immutable. JS has always hade 'freeze' as a kind of runtime immutability, and tooling like TS can provide for readonly types that provide immutability guarantees at compile time.
  - everforward 1y ago
    Arrays are a very notable example here. You can append to a const array in JS and TS, even in the same scope it was declared const. That’s always felt very odd to me.
    - raddan 1y ago
      That's because in many languages there is a difference between a stored reference being immutable and the contents of the thing the reference points to being immutable.
    - deleted 1y ago
      [deleted]
    - DemocracyFTW2 1y ago
      I think JavaScript has a language / terminology problem here. It has to be explained constantly (see) to newcomers that `const a = []` does not imply you cannot say `a.push( x )` (mutation), it just keeps you from being able to say `a = x` further down (re-binding). Since in JavaScript objects always start life as mutable things, but primitives are inherently immutable, `const a = 4` does guarantee `a` will be `4` down the line, though. The same is true of `const a = Object.freeze( [] )` (`a` will always be the empty list), but, lo and behold, you can still add elements to `a` even after `const a = Object.freeze( new Set() )` which is, shall we say, unfortunate. The vagaries don't end there. NodeJS' `assert` namespace has methods like `equal()`, `strictEqual()`, `deepEqual()`, `deepStrictEqual()`, and `partialDeepStrictEqual()`, which is both excessive and badly named (although there's good justification for what `partialDeepStrictEqual()` does); ideally, `equal()` should be both `strict` and `deep`. That this is also a terminology problem is borne out by explanations that oftentimes do not clearly differentiate between object value and object identity. In a language with inherent immutability, object value and object identity may (conceptually at least) be conflated, like they are for JavaScript's primitive values. You can always assume that an `'abc'` over here has the same object identity (memory location) as that `'abc'` over there, because it couldn't possibly make a difference were it not the case. The same should be true of an immutable list: for all we know, and all we have to know, two immutable lists could be stored in the same memory when they share the same elements in the same order.
- skeezyjefferson 1y ago
  but we already had the word variable for values that can change. on both counts it seems redundant
  - Thorrez 1y ago
    Oh, good point. I misunderstood your previous question. Is there a name that refers to the broader group that includes both constants and variables? In practice, and in e.g. C++, "variable" is used to refer to both constants and actual variables, due to there not being a different common name that can be used to refer to both.
inanutshellus 1y ago
"Constant" implies a larger context. As in - it's not very "constant" if you keep re-making it in your loop, right? Whereas "immutable" throws away that extra context and means "whatever variable you have, for however long you have it, it's unchangeable."
- skeezyjefferson 1y ago
  > As in - it's not very "constant" if you keep re-making it in your loop, right? you cant change a constant though
  - veilrap 1y ago
    He’s implying that the variable it’s being defined within the loop. So, constant, but repeatedly redefined.
    - ghurtado 1y ago
      That's the opposite of what any reasonable engineer means by "constant".
      - fnordsensei 1y ago
        That’s the point, you’re just haggling about scopes now. All the way from being new per program invocation to new per loop. Immutability doesn’t have this connotation.
        davrosthedalek 1y ago
        How? I think the same argument applies: If it's changing from loop to loop, seems mutable to me.
        fnordsensei 1y ago
        I think you’re after something other than immutability then. You’re allowed to rebind a var defined within a loop, it doesn’t mean that you can’t hang on to the old value if you need to. With mutability, you actively can’t hang on to the old value, it’ll change under your feet. Maybe it makes more sense if you think about it like tail recursion: you call a function and do some calculations, and then you call the same function again, but with new args. This is allowed, and not the same as hammering a variable in place.
scott_w 1y ago
In plenty of languages, there's not really a difference. In Rust, there is a difference between a `let var_name = 10;` and `const var_name: u64 = 10;` in that the latter must have its value known at compile-time (it's a true constant). > why are you calling it mutable? Mostly just convention. Rust has immutable by default and you have to mark variables specifically with `mut` (so `let mut var_name = 10;`). Other languages distinguish between variables and values, so var and val, or something like that. Or they might do var and const (JS does this I think) to be more distinct.
munificent 1y ago
"Constant" is ambiguous. Depending on who you ask, it can mean either: 1. A property known at compile time. 2. A property that can't change after being initially computed. Many of the benefits of immutability accrue properties whose values are only known at runtime but which are still known to not change after that point.
- throwaway2037 1y ago
  DotNet/C# makes this distinction in the form of (1) const and (2) readonly.

Immutable and constant are the same. rendaw didn't use the word mutable. One reason someone might use the word "mutable" is that it's a succinct way of expressing an idea. Alternative ways of expressing the same idea are longer words (changeable, non-constant).

kgwxd 1y ago
They aren't the same for object references. The reference can't be changed, but the properties can.
- Thorrez 1y ago
  Depends on the language. In C++ const std::vector<int>& foo = bar.GetVector(); foo is a constant object reference cannot have its properties changed (and also cannot be changed to refer to a new object). std::vector<int>& foo = bar.GetVector(); Is an object reference that can have its properties changed (but cannot be changed to refer to a new object).
a4isms 1y ago
In languages like JavaScript, immutable and constant may be theoretically the same thing, but in practice "const" means a variable cannot be reassigned, while "immutable" means a value cannot be mutated in place. They are very, very different semantically, because const is always local. Declaring something const has no effect on what happens with the value bound to a const variable anywhere else in the program. Whereas, immutability is a global property: An immutable array, for example, can be passed around and it will always be immutable. JS has always hade 'freeze' as a kind of runtime immutability, and tooling like TS can provide for readonly types that provide immutability guarantees at compile time.
- everforward 1y ago
  Arrays are a very notable example here. You can append to a const array in JS and TS, even in the same scope it was declared const. That’s always felt very odd to me.
  - raddan 1y ago
    That's because in many languages there is a difference between a stored reference being immutable and the contents of the thing the reference points to being immutable.
  - deleted 1y ago
    [deleted]
  - DemocracyFTW2 1y ago
    I think JavaScript has a language / terminology problem here. It has to be explained constantly (see) to newcomers that `const a = []` does not imply you cannot say `a.push( x )` (mutation), it just keeps you from being able to say `a = x` further down (re-binding). Since in JavaScript objects always start life as mutable things, but primitives are inherently immutable, `const a = 4` does guarantee `a` will be `4` down the line, though. The same is true of `const a = Object.freeze( [] )` (`a` will always be the empty list), but, lo and behold, you can still add elements to `a` even after `const a = Object.freeze( new Set() )` which is, shall we say, unfortunate. The vagaries don't end there. NodeJS' `assert` namespace has methods like `equal()`, `strictEqual()`, `deepEqual()`, `deepStrictEqual()`, and `partialDeepStrictEqual()`, which is both excessive and badly named (although there's good justification for what `partialDeepStrictEqual()` does); ideally, `equal()` should be both `strict` and `deep`. That this is also a terminology problem is borne out by explanations that oftentimes do not clearly differentiate between object value and object identity. In a language with inherent immutability, object value and object identity may (conceptually at least) be conflated, like they are for JavaScript's primitive values. You can always assume that an `'abc'` over here has the same object identity (memory location) as that `'abc'` over there, because it couldn't possibly make a difference were it not the case. The same should be true of an immutable list: for all we know, and all we have to know, two immutable lists could be stored in the same memory when they share the same elements in the same order.
skeezyjefferson 1y ago
but we already had the word variable for values that can change. on both counts it seems redundant
- Thorrez 1y ago
  Oh, good point. I misunderstood your previous question. Is there a name that refers to the broader group that includes both constants and variables? In practice, and in e.g. C++, "variable" is used to refer to both constants and actual variables, due to there not being a different common name that can be used to refer to both.

inanutshellus 1y ago

"Constant" implies a larger context. As in - it's not very "constant" if you keep re-making it in your loop, right? Whereas "immutable" throws away that extra context and means "whatever variable you have, for however long you have it, it's unchangeable."

skeezyjefferson 1y ago
> As in - it's not very "constant" if you keep re-making it in your loop, right? you cant change a constant though
- veilrap 1y ago
  He’s implying that the variable it’s being defined within the loop. So, constant, but repeatedly redefined.
  - ghurtado 1y ago
    That's the opposite of what any reasonable engineer means by "constant".
    - fnordsensei 1y ago
      That’s the point, you’re just haggling about scopes now. All the way from being new per program invocation to new per loop. Immutability doesn’t have this connotation.
      - davrosthedalek 1y ago
        How? I think the same argument applies: If it's changing from loop to loop, seems mutable to me.
        fnordsensei 1y ago
        I think you’re after something other than immutability then. You’re allowed to rebind a var defined within a loop, it doesn’t mean that you can’t hang on to the old value if you need to. With mutability, you actively can’t hang on to the old value, it’ll change under your feet. Maybe it makes more sense if you think about it like tail recursion: you call a function and do some calculations, and then you call the same function again, but with new args. This is allowed, and not the same as hammering a variable in place.

scott_w 1y ago

In plenty of languages, there's not really a difference. In Rust, there is a difference between a `let var_name = 10;` and `const var_name: u64 = 10;` in that the latter must have its value known at compile-time (it's a true constant). > why are you calling it mutable? Mostly just convention. Rust has immutable by default and you have to mark variables specifically with `mut` (so `let mut var_name = 10;`). Other languages distinguish between variables and values, so var and val, or something like that. Or they might do var and const (JS does this I think) to be more distinct.

munificent 1y ago

"Constant" is ambiguous. Depending on who you ask, it can mean either: 1. A property known at compile time. 2. A property that can't change after being initially computed. Many of the benefits of immutability accrue properties whose values are only known at runtime but which are still known to not change after that point.

throwaway2037 1y ago
DotNet/C# makes this distinction in the form of (1) const and (2) readonly.