Comment by a_humean | Hacker News Reader

Comment by a_humean | Hacker News Reader

Parent Full thread

edit: don't vote the guy/gal down just because they are admitting some ignorance and seeking clarity

I would quickly disabuse yourself of the notion that all values are immutable in JavaScript, as otherwise you will cause yourself and colleagues a lot of pain in future. As someone that has to write or maintain a lot of JavaScript, saying that I don't have to think about data changing over the course of a program doesn't strike me as true at all (I wish it was).

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Data...

As linked, only some of the primitive values in javascript are immutable. So while you can be confident in this:

const x = 'a perfectly well formed string';

// lots of code in between

console.log(x) // will always print 'a perfectly well formed string'

You cannot be confident in this at all:

const x = {

  a: 'a perfectly well formed string within an object'

};

// lots of code in between

console.log(x.a) // absolutely no guarantee that x.a will point at the same string as at the time x was initialized as an object, or that the key will even exist (will fallback to the type 'undefined' if you attempt to read it).

JavaScript has references and values like most languages, but you aren't dealing with memory as explicitly as Rust or C. The reason is in large part because memory is garbage collected in Javascript.

That's because the real value is the object identity, not its state. Trust me, object identities are immutable.

That's like saying the pointer 0x123456 is immutable. Which is strictly speaking true, even in a language as lax as C. But it's clearly not what people mean when they talk about pointers (or references) being mutable. What people mean is that either variables are mutable, or memory is. So if you say:

    // suppose initially x == 0x123456 and x has type char *
    x++
    // x == 0x123457

this is really changing the value of a variable (neither of the pointers 0x123456 or 0x123457 have been changed in any way).

Or if you say:

    *x = 'a'

now you're modifying the memory at the address 0x123457 (again, the pointer itself has not changed).

The fact that the pointer itself, as in the address to memory (as opposed to the variable holding that address or the contents of the memory being referred to) is immutable is of approximately no value to anyone.

And frankly, it makes no difference (for these examples) whether this is a language with pointers or references. You can still set variables holding references to new values (if the language allows mutable variables), and you can still mutate the memory that references address (if the language allows mutation of the objects referred to by references), and that's plenty of rope to hang yourself on even without being able to do pointer arithmetic on the address values.

> But it's clearly not what people mean when they talk about pointers (or references) being mutable.

The semantics of a programming language is what it is, not what you want it to be, unless you explicitly choose a language that allows you to express exactly what you mean.

The semantics of a programming language isn't determined by how you talk about it or even how the language specification talks about it.

The original statement was: "(I program in JavaScript where all values are immutable)" Its meaning depends on the semantics of 'values' and 'immutable'. If by 'values' you only mean primitive values (excluding objects and arrays) or by immutable you only mean immutable identity (excluding mutable state), you're comparing apples to oranges instead of Rust to JavaScript.

Immutable.js and PureScript exists for a reason: in JavaScript, not all values are immutable.

> in JavaScript, not all values are immutable.

Object states are mutable, of course. But they are not values. You can't bind object states to variables. If you use objects as proxies for values that exist in your head but not in in JavaScript's semantics, that's fine, so long as you keep in mind the distinction between what you wish you were using and what you are actually using.

Reply on news.ycombinator.com