storing other references to the actual values of 1, 2, 3.
That depends as the runtime can optimize. See Elements kinds in V8. Also there are Typed Arrays which hold the actual (uniformly typed) values.
Ryan Cavanaugh
@searyanc
JavaScript performance is bananas, a thread.
Let's write a function to sum the values from a the 'val' property of each element in an array:
function sum(arr) { let acc = 0; for (let i = 0; i < arr.length; i++) { acc += arr[i].val; } return acc; }
1/10
00:01 AM - 23 Feb 2022
It is shocking that even for primitive types, the JS variable only holds a reference (address in JS) to the actual value.
Remember that the runtime is free to optimize whichever way it seems fit as long as the observable behaviour aligns with the language specification. However it is dictated that the conceptual behaviour of a value of a primitive type is that of an "immutable datum represented directly at the lowest level of the language". Immutability is easily explained with Strings; you can't change a string, you can only create a new one, so on "assignment" the let name is essentially being rebound to the new string. But Boolean, NullUndefined, Number, BigInt, and Symbol values all behave the same way by virtue of being primitive types. I seem to remember coming across some V8 source code where primitive JavaScript values (at least in some context) were represented by C++ classes.
So basically, 90%+ of the materials out there are wrong
It's a simplified mental model which mostly works and is easy to grasp for beginners.
which is wrong based on the discussion here (right?)
Again the runtime implementation isn't dictated. V8 has the "Ignition" interpreter and the "Turbofan" compiler so actual JS execution could be accomplished in very different ways depending on the level of optimization.
if that variable metaphor idea will differ in different languages (Java vs JavaScript or even others).
My metaphor isn't original. Given that in JavaScript primitive values are immutable it's unfortunate that the term "assignment" is being used as that implies PLOP (PLace-Oriented Programming), i.e. (re)placing a value inside a location giving rise to the notion of a "variable" as the value inside the location can vary. In value-oriented programming (typically practiced in functional languages)
letnumber=1983;
is binding the name number to the value 1983 while
number=number*10;
is rebinding the name number to the result of the number * 10 expression. With that terminology it is the binding that changes, not the value.
I only stumbled upon this because I got annoyed at const—until I discovered:
"The const declaration creates a read-only reference to a value. It does not mean the value it holds is immutable—just that the variable identifier cannot be reassigned."
So people keep saying that const works differently for primitive values and objects (overlooking completely that primitive values are already immutable). This is a perspective that becomes necessary because of the assignment/variable oversimplification that people learn in the beginning. The truth is much simpler:
const doesn't act on the value but on the binding—it's the binding that is constant and unchangeable. As a result the const behaviour is absolutely identical for primitive values and objects as the binding being constant does not affect the internal mutability of objects (which includes arrays).
If I don't want to touch on any details about virtual memory
I hope I conveyed that going to that level isn't actually necessary. Once you eliminate the notion of variables and assignments and replace them entirely with names and bindings, everything behaves entirely consistently. It's just that beginners material insists on starting with variables and assignments and then never adjust that initial mental model.
Thanks for your reply, let me study more with the given directions.
My imdidate response to this
Remember that the runtime is free to optimize whichever way it seems fit as long as the observable behaviour aligns with the language specification.
Yeah, it makes a lot of sense. For example, in C/C++, the "Optimization" I learned is like out-of-order execution (including speculation) and unfolding loops. I remember back then, I was shocked as well. Now I realize it is not just the JavaScript tutorials problem. One of the utimate problems is that the teaching materials don't separate what the language specifications are. But for non-specified behaviors, they are subjected to be changed/optimized. I think this is also a missing mental model puzzle here.
Back then, our university C++/Java course should also focus more on the language specifications first and make a clear separation between abstraction and implementation. Now I am confused about what I have learned (for all languages what their specifications/promises are).
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
That depends as the runtime can optimize. See Elements kinds in V8. Also there are Typed Arrays which hold the actual (uniformly typed) values.
Remember that the runtime is free to optimize whichever way it seems fit as long as the observable behaviour aligns with the language specification. However it is dictated that the conceptual behaviour of a value of a primitive type is that of an "immutable datum represented directly at the lowest level of the language". Immutability is easily explained with
String
s; you can't change a string, you can only create a new one, so on "assignment" thelet
name is essentially being rebound to the new string. ButBoolean
,Null
Undefined
,Number
,BigInt
, andSymbol
values all behave the same way by virtue of being primitive types. I seem to remember coming across some V8 source code where primitive JavaScript values (at least in some context) were represented by C++ classes.It's a simplified mental model which mostly works and is easy to grasp for beginners.
Again the runtime implementation isn't dictated. V8 has the "Ignition" interpreter and the "Turbofan" compiler so actual JS execution could be accomplished in very different ways depending on the level of optimization.
My metaphor isn't original. Given that in JavaScript primitive values are immutable it's unfortunate that the term "assignment" is being used as that implies PLOP (PLace-Oriented Programming), i.e. (re)placing a value inside a location giving rise to the notion of a "variable" as the value inside the location can vary. In value-oriented programming (typically practiced in functional languages)
is binding the name
number
to the value1983
whileis rebinding the name
number
to the result of thenumber * 10
expression. With that terminology it is the binding that changes, not the value.I only stumbled upon this because I got annoyed at
const
—until I discovered:"The
const
declaration creates a read-only reference to a value. It does not mean the value it holds is immutable—just that the variable identifier cannot be reassigned."So people keep saying that
const
works differently for primitive values and objects (overlooking completely that primitive values are already immutable). This is a perspective that becomes necessary because of the assignment/variable oversimplification that people learn in the beginning. The truth is much simpler:const
doesn't act on the value but on the binding—it's the binding that is constant and unchangeable. As a result theconst
behaviour is absolutely identical for primitive values and objects as the binding being constant does not affect the internal mutability of objects (which includes arrays).I hope I conveyed that going to that level isn't actually necessary. Once you eliminate the notion of variables and assignments and replace them entirely with names and bindings, everything behaves entirely consistently. It's just that beginners material insists on starting with variables and assignments and then never adjust that initial mental model.
Thanks for your reply, let me study more with the given directions.
My imdidate response to this
Yeah, it makes a lot of sense. For example, in C/C++, the "Optimization" I learned is like out-of-order execution (including speculation) and unfolding loops. I remember back then, I was shocked as well. Now I realize it is not just the JavaScript tutorials problem. One of the utimate problems is that the teaching materials don't separate what the language specifications are. But for non-specified behaviors, they are subjected to be changed/optimized. I think this is also a missing mental model puzzle here.
Back then, our university C++/Java course should also focus more on the language specifications first and make a clear separation between abstraction and implementation. Now I am confused about what I have learned (for all languages what their specifications/promises are).