const value can be redeclared in a different scope - but to be very precise; this is not really question of (im)mutability - it is a different value inside a scope, the original value is not changed.
Other thing is (and I believe this is what the OP is asking you) - if you say:
const a = 1;
a will always be 1 (inside the scope).
Sure if you say:
const o = { a: 1};
you can change the value of a inside the o, but the o (the pointer as the OP is saying) is not changed. I have 0 experience with Elm, but a _lot_ of popular languages have this behaviour for const/final
It's not useful to describe the behaviour of "pointers" in JavaScript, because JavaScript does not have pointers[0].
I think the article I linked to earlier was already sufficiently unambiguous. To clarify once again: If you can mutate a value, then the value is mutable. Mutable means it is not immutable. The `const` keyword in JavaScript does not give you an immutable value.
I used the terminology that the OP used to be more clear. Pointer or reference in this context is not so significant as is that 'const' is marking the reference (OP used "pointer") as a constant, and not the value that is referring to.
Point the OP was getting at:
'const' gives you an immutable reference to a mutable value because it is a modifier for the reference and not the value.
Yes, the article you linked was unambiguous, but for another question :)
As i said, a lot of langugaes (I don't know any that behaves differently) uses the const/final modifiers in this way.
In my experience with people that are just learning how to code, it is a more efficient to point out what is the 'const' modifier making a constant of, than pointing out what it does not do, because the latter sometimes sends a message that the 'const' is useless as it 'does not do anything'.
Yes precisely this. The person above you might be unaware of the fact but JavaScript (and all other languages that I’m aware of) does indeed make use of pointers albeit indirectly. When you use const and initialize it as a JS object the value in the variable is a “pointer” (call it what you will, it points to or references a memory location) and is indeed immutable. You cannot change the value of the variable. You can, however, change the value of a different variable (such as a property of the object it references) but at that point you’re not longer talking about the same variable. So in a sense “no, it’s not immutable” but in another sense, yes it actually is. It makes the most sense to talk about the value that the variable holds rather than the object it references when speaking of immutability because there also exist primitive values in JS that are immutable in exactly the same way, except they are not references (or pointers) they are just values. So instead of needing to keep the additional “gotcha, object references are immutable but the properties of that object are not frozen” you can simply understand the literal semantics. Of course that is just my personal opinion
Do you think your 200-word explanation is easier for a beginner to understand than "this value is immutable — it will never change"?
My initial argument was that JavaScript is a terrible choice for learning FP, precisely because it has so many caveats and is notoriously poorly understood, even by people who use it every day. Your lengthy explanation proves my point.
I find this argument a bit disingenuous to be honest, I took the liberty of spelling things out in my reply because I assumed you wouldn’t otherwise be able to see the point. An explanation to a beginner, which doesn’t require memorizing any additional gotchas, would be something like “variables hold values. Strings, numbers, booleans, and references are values. Variables declared with const contain values that are immutable. An object is not a value.”
Perhaps this would be clearer: "The identity of a const object is immutable but its state can be mutable."