Have you given any kind of training or lessons in programming (honest question)? Everything can break down!
This is exactly what I’m talking about:
> The binding b points to the same value that a points to
It may look obvious to you, but someone will interpret “the same value” as literally the same. So they might expect a change in a to reflect on b. Whereas if you tell them the “a box contains 22” and “the b box also contains 22” you prevent that misunderstanding. They might not have any concept of references/pointers yet and are just trying to make sense out of everything. These are the kind of silly mistakes people make when learning programming, or a new language.
It’s not about being right or wrong but providing a safe path to understanding that can be built upon. I did not mean the binding/tentacle abstraction is wrong, just that there might be a simpler one to introduce the concept. The book is still great regardless.
> It may look obvious to you, but someone will interpret “the same value” as literally the same.
But it is literally the same? Numbers are immutable, so there is a performance optimization where you can avoid using pointers internally, but the fact that they are immutable also means there is no way to distinguish between them being the same value and them being "different instances".
If you do `let a = []; let b = a; a = [1]` would your students expect that b equals [1] or would they understand that a and b now contain different arrays? If the latter, then why would think that after `let a = 22; let b = a; a = 50;` b also equals 50?
> Have you given any kind of training or lessons in programming (honest question)? Everything can break down!
I have actually, so I understand what you mean, that all sorts of confusions are possible no matter what. I agree with you on that part; I just disagree that the “boxes” metaphor is something that is necessary or “needed later” (what I understood from the wording “This method spares the reader one step, but might cause confusion once they face problems that require that understanding” or “breaks down”).
Yes, the student needs to understand that “let b = a” assigns to b the value of a, and does not make b a permanent alias for a. To some students that misconception may never arise, but to others it might and that is something to watch out for. (This is the part explained here for instance: https://nedbatchelder.com/text/names1.html#:~:text=I%E2%80%9... — sorry if you cannot see the highlighted part e.g. if you're using Firefox (https://caniuse.com/url-scroll-to-text-fragment), look before and after "Reassigning one of them".) But if you explain this as “the a box contains 22” and “the b box also contains 22”, this is an understanding that only applies to primitive values and therefore will break down pretty soon and cause confusion (given how widely non-primitive values are used in JS/Python/etc), while if you say that “let b = a” makes the “b tentacle” point to the value that the “a tentacle” points to, this is a uniform understanding that bypasses the incomplete “boxes” understanding. With the understanding that names are one kind of thing and values are another, and names can only point to values (not to other names), there is no problem with “the same value” being interpreted as literally the same: it is literally the same value (a Platonic ideal “22” that lives out there and that both a and b point to), and a re-assignment like a = 23 does not change the value (the notion of changing a value would not even arise without the boxes metaphor, as value 22 and value 23 are simply different things on the values side).
But I guess ultimately this is an empirical matter: we can try the different paths on different sets of students and over time see which one takes better. My intuition is that the “tentacles” metaphor is just as easy to understand as “boxes” without the latter's problems (there are risks common to both, e.g. "let b = a" neither makes the b tentacle point to a itself, nor does it put the a box inside the b box), but until we actually try it out (I have not tried to compare), I guess we just have different intuitions for now. :-)
This is exactly what I’m talking about:
> The binding b points to the same value that a points to
It may look obvious to you, but someone will interpret “the same value” as literally the same. So they might expect a change in a to reflect on b. Whereas if you tell them the “a box contains 22” and “the b box also contains 22” you prevent that misunderstanding. They might not have any concept of references/pointers yet and are just trying to make sense out of everything. These are the kind of silly mistakes people make when learning programming, or a new language.
It’s not about being right or wrong but providing a safe path to understanding that can be built upon. I did not mean the binding/tentacle abstraction is wrong, just that there might be a simpler one to introduce the concept. The book is still great regardless.