5 ms·

I love this book, even since its first edition. It's very clear even on elementary stuff, e.g. see the section on bindings/variables: https://eloquentjavascrip

by svat 3y ago

I love this book, even since its first edition. It's very clear even on elementary stuff, e.g. see the section on bindings/variables: https://eloquentjavascript.net/02_program_structure.html#h-lnOC+GBEtu https://eloquentjavascript.net/02_program_structure.html#h-l... — avoids the pitfall of thinking of variables as “boxes”. I was trying to find what's new in the 4th edition, and following links from the author's website https://marijnhaverbeke.nl/ https://marijnhaverbeke.nl/ found this on Mastodon (https://mastodon.social/@marijn/112020092273623390 https://mastodon.social/@marijn/112020092273623390): > The FOURTH EDITION of Eloquent JavaScript is now online, adjusted to the realities of 2024 and generally touched up.

shippintoboston 3y ago
[dead]
DenverSWE 3y ago
Looks as if there will still be a paperback version released in the future as well for anyone that prefers that format. I don't work in JS at all professionally but this book has intrigued me for a while at this point after seeing it recommended so often. I think I'll pick up a copy once the paperback is released.
ricardobeat 3y ago
It's a great explanation, but I've never heard the term 'binding' used to describe variables. It's usually reserved to function binding or bridge APIs like the DOM. The tricky thing is that "boxes" are the right abstraction for primitive values. After that you need to explain how references work, and that's pretty much the same 'tentacle' concept. This method spares the reader one step, but might cause confusion once they face problems that require that understanding.
- pier25 3y ago
  "binding" seems like a more casual term for memory pointer. I guess if people are just getting started with programming it make sense to simplify things a bit.
  - svat 3y ago
    My point is that it's not a simplification, it's precisely how the language works: bindings between values and names (JavaScript has no separate notion of memory pointer; everything is a "pointer"). (Similarly for Python: https://nedbatchelder.com/text/names1.html https://nedbatchelder.com/text/names1.html) Describing variables in this way gives readers the correct understanding, and the analogy of tentacles is no harder than that of boxes. Such things are what I most appreciated, that the author manages to be approachable without sacrificing accuracy.
    - pier25 3y ago
      If the explanation doesn't mention memory positions then it is a simplification.
      - svat 3y ago
        JavaScript does not provide a way for the programmer to access memory positions (and e.g. does not guarantee that the the language runtime will maintain unvarying memory positions), so it doesn't make sense to talk about memory positions: there's nothing to be gained at that level of abstraction. (Unless you'd call it a "simplification" to not talk of electrons and transistors too, in which case fine, yes it's a simplification in that sense.)
  - kazinator 3y ago
    It's not a simplification. It is abstraction. Binding doesn't imply a particular implementation. A variable binding can disappear entirely. If you bind var x = 42 and never use it, the variable need not exist. If it doesn't exist, then there is no pointer. If you do use it, constant propagation/folding can again make the variable disappear. If the variable is never assigned, all uses of it can be replaced with 2. Variables that care captured by lexical closures can be treated differently from ones that are not. Variables captured by closures but not shared among different closures, or not mutated, can be treated differently from mutated variables shared among closures. The abstraction of binding is more complicated than "every variable is a memory pointer" because it allows more possibilities, which can coexist.
- michaelcampbell 3y ago
  "binding" is pretty standard terminology in some oldtimey languages; lisp, ML, etc.
  - kazinator 3y ago
    Bash documentation says that "set -u" traps variables that are "unset". The actual diagnostic itself is better educated: $ set -u $ asdasdf $ echo $asdasdf bash: asdasdf: unbound variable
- jameshart 3y ago
  1) the most common binding used in well written modern JavaScript is a const binding. It is by definition not a variable. 2) the ‘binding/tentacle’ metaphor works just fine for primitives and the ‘boxes’ model adds more complexity.
- NlightNFotis 3y ago
  "binding" is a PLT term, denoting the association between a name and a value. It's a higher level concept than the variable - a mutable binding is what people usually refer to as a variable, and an immutable binding is the correct term for what people refer to an "immutable variable" (an oxymoron, if you think about it).
  - skitter 3y ago
    Immutable variable isn't a oxymoron. It can still vary between instantiations. If you have (a)=>{const b = a}, b can have different values even though it can't be reassigned.
    - NlightNFotis 3y ago
      In the case of the code that you have cited, these are all different elaborations of the binding at the invocation of the lambda, due to the interplay between activation records and scope rules. It's not really an "immutable variable" - it's a local binding getting bound to different values on each scope entry. EDIT: By the way, the `b` binding in your code can be modified. Did you mean `const b = a;` ?
      - skitter 3y ago
        > it's a local binding getting bound to different values on each scope entry. It is, I just wanted to point out that the term "immutable variable" is sensible. I think a good way to put it is that b is a variable, and when the statement runs a value is bound to b. So the value bound to b varies yet b can be immutable, in contrast to a constant which is a binding to always the same value. > Did you mean `const b = a;` ? Fixed, thanks :)
- svat 3y ago
  "Binding" is used thousands of times in the language standard, including for variables: https://tc39.es/ecma262/#sec-variable-statement https://tc39.es/ecma262/#sec-variable-statement -- that's my point, that this book is precise while being approachable to beginners. And I dispute the claim that "boxes" are the right abstraction for anything in JS. (Boxes may work for primitive values, but nothing further.) Directly seeing names as bindings ("tentacles") not only skips the incorrect "boxes" step, but also causes no confusion or problems whatsoever at any point. (If you have an example, I'd be curious to see it.) (There are some differences in the language between primitive values and Object, but none of them are particularly helped treating variables as boxes AFAICT.)
  - ricardobeat 3y ago
    I meant in the context of writing code - you’ll never hear anyone refer to their “bindings”. It breaks down with the simple `let a = 22; let b = a` example where the tentacle/binding metaphor can lead to wrong intuition of why a change to the value of a is not reflected in b.
    - throwanem 3y ago
      You're struggling due to a conflation of two concepts. Binding refers to associating a name with a value. Assignment is a case of binding, but not the only one; two other examples are positional arguments in a function signature, and ESM imports. A binding can be mutable (let assignment, function arguments) or immutable (const assignment, ESM import). Value mutability is orthogonal. You can mutably bind a primitive value as "let a = 22" and then mutate the binding via reassignment, but you can't mutate the value itself; you can immutably bind a reference value as "const b = {}" and mutate the referenced object via property access, but you can't mutate the binding. I refer to bindings all the time, where it's useful to be clear in meaning. I also make sure to introduce the concept to mentees who aren't already familiar with it, and by all reports thus far it's proven as valuable an abstraction for them as it did for me when I first learned of it.
      - ricardobeat 3y ago
- deleted 3y ago
  [deleted]
arrowleaf 3y ago
The book is actually maintained on GitHub too, https://github.com/marijnh/Eloquent-JavaScript https://github.com/marijnh/Eloquent-JavaScript. When I was just starting out I read this book and noticed a small mistake, I was really proud that one of my first contributions to any open source project was a PR to this repo.
- svat 3y ago
  Thanks, that gives a way of seeing the diff between the third edition and the current (last commit 45 minutes ago): https://github.com/marijnh/Eloquent-JavaScript/compare/f8f004f..08cfb2a https://github.com/marijnh/Eloquent-JavaScript/compare/f8f00...
MikeTheGreat 3y ago
I'm curious - could you expand on why it's a pitfall to think of variables as boxes?
- svat 3y ago
  Because that's not how variables work in JavaScript/Python etc (though it may be fine for say C++ in the case of value types and copy constructors). For example: I'm typing on phone so for a quick example: let a = []; let b = a; a.push(1); and consider the value of b now (or the fact that we could write "const" above because the binding is constant, even though we mutate the value). Or see the equivalent for Python by Ned Batchelder, which has more examples and elaboration: https://nedbatchelder.com/text/names1.html https://nedbatchelder.com/text/names1.html
  - MikeTheGreat 3y ago
    I knew that in Python all variables are really references to objects (even when we're using a number) - is JavaScript the same way? Also, does anyone have a link/reference to the place in the spec where it specifies this? I briefly skimmed through parts of [1] but couldn't find anything that says that JavaScript treats numbers this way. [1] https://tc39.es/ecma262/multipage/#sec-intro https://tc39.es/ecma262/multipage/#sec-intro
    - culturedsystems 3y ago
      I don't think there's an explicit reference in the JavaScript spec to numbers being treated this way, because this is how all variables are treated in JavaScript - the relevant part of the specification is probably the definition of the "PutValue" abstract operation[1], which doesn't include any special cases for numbers (or other primitive types) vs. objects. [1] https://tc39.es/ecma262/multipage/ecmascript-data-types-and-values.html#sec-putvalue https://tc39.es/ecma262/multipage/ecmascript-data-types-and-...
    - svat 3y ago
      As I understand it, JavaScript does have a distinction between the primitive types and Object, but this does not show up in any significant way to the programmer / in any way relevant to how to view variables. To put it differently, the "boxes" view only applies to primitive values, while the "tentacles" view applies to all values, so the former is unnecessary and need not even be considered/taught.

by svat 3y ago

shippintoboston 3y ago

[dead]

DenverSWE 3y ago

Looks as if there will still be a paperback version released in the future as well for anyone that prefers that format. I don't work in JS at all professionally but this book has intrigued me for a while at this point after seeing it recommended so often. I think I'll pick up a copy once the paperback is released.

ricardobeat 3y ago

It's a great explanation, but I've never heard the term 'binding' used to describe variables. It's usually reserved to function binding or bridge APIs like the DOM. The tricky thing is that "boxes" are the right abstraction for primitive values. After that you need to explain how references work, and that's pretty much the same 'tentacle' concept. This method spares the reader one step, but might cause confusion once they face problems that require that understanding.

pier25 3y ago
"binding" seems like a more casual term for memory pointer. I guess if people are just getting started with programming it make sense to simplify things a bit.
- svat 3y ago
  My point is that it's not a simplification, it's precisely how the language works: bindings between values and names (JavaScript has no separate notion of memory pointer; everything is a "pointer"). (Similarly for Python: https://nedbatchelder.com/text/names1.html https://nedbatchelder.com/text/names1.html) Describing variables in this way gives readers the correct understanding, and the analogy of tentacles is no harder than that of boxes. Such things are what I most appreciated, that the author manages to be approachable without sacrificing accuracy.
  - pier25 3y ago
    If the explanation doesn't mention memory positions then it is a simplification.
    - svat 3y ago
      JavaScript does not provide a way for the programmer to access memory positions (and e.g. does not guarantee that the the language runtime will maintain unvarying memory positions), so it doesn't make sense to talk about memory positions: there's nothing to be gained at that level of abstraction. (Unless you'd call it a "simplification" to not talk of electrons and transistors too, in which case fine, yes it's a simplification in that sense.)
- kazinator 3y ago
  It's not a simplification. It is abstraction. Binding doesn't imply a particular implementation. A variable binding can disappear entirely. If you bind var x = 42 and never use it, the variable need not exist. If it doesn't exist, then there is no pointer. If you do use it, constant propagation/folding can again make the variable disappear. If the variable is never assigned, all uses of it can be replaced with 2. Variables that care captured by lexical closures can be treated differently from ones that are not. Variables captured by closures but not shared among different closures, or not mutated, can be treated differently from mutated variables shared among closures. The abstraction of binding is more complicated than "every variable is a memory pointer" because it allows more possibilities, which can coexist.
michaelcampbell 3y ago
"binding" is pretty standard terminology in some oldtimey languages; lisp, ML, etc.
- kazinator 3y ago
  Bash documentation says that "set -u" traps variables that are "unset". The actual diagnostic itself is better educated: $ set -u $ asdasdf $ echo $asdasdf bash: asdasdf: unbound variable
jameshart 3y ago
1) the most common binding used in well written modern JavaScript is a const binding. It is by definition not a variable. 2) the ‘binding/tentacle’ metaphor works just fine for primitives and the ‘boxes’ model adds more complexity.
NlightNFotis 3y ago
"binding" is a PLT term, denoting the association between a name and a value. It's a higher level concept than the variable - a mutable binding is what people usually refer to as a variable, and an immutable binding is the correct term for what people refer to an "immutable variable" (an oxymoron, if you think about it).
- skitter 3y ago
  Immutable variable isn't a oxymoron. It can still vary between instantiations. If you have (a)=>{const b = a}, b can have different values even though it can't be reassigned.
  - NlightNFotis 3y ago
    In the case of the code that you have cited, these are all different elaborations of the binding at the invocation of the lambda, due to the interplay between activation records and scope rules. It's not really an "immutable variable" - it's a local binding getting bound to different values on each scope entry. EDIT: By the way, the `b` binding in your code can be modified. Did you mean `const b = a;` ?
    - skitter 3y ago
      > it's a local binding getting bound to different values on each scope entry. It is, I just wanted to point out that the term "immutable variable" is sensible. I think a good way to put it is that b is a variable, and when the statement runs a value is bound to b. So the value bound to b varies yet b can be immutable, in contrast to a constant which is a binding to always the same value. > Did you mean `const b = a;` ? Fixed, thanks :)
svat 3y ago
"Binding" is used thousands of times in the language standard, including for variables: https://tc39.es/ecma262/#sec-variable-statement https://tc39.es/ecma262/#sec-variable-statement -- that's my point, that this book is precise while being approachable to beginners. And I dispute the claim that "boxes" are the right abstraction for anything in JS. (Boxes may work for primitive values, but nothing further.) Directly seeing names as bindings ("tentacles") not only skips the incorrect "boxes" step, but also causes no confusion or problems whatsoever at any point. (If you have an example, I'd be curious to see it.) (There are some differences in the language between primitive values and Object, but none of them are particularly helped treating variables as boxes AFAICT.)
- ricardobeat 3y ago
  I meant in the context of writing code - you’ll never hear anyone refer to their “bindings”. It breaks down with the simple `let a = 22; let b = a` example where the tentacle/binding metaphor can lead to wrong intuition of why a change to the value of a is not reflected in b.
  - throwanem 3y ago
    You're struggling due to a conflation of two concepts. Binding refers to associating a name with a value. Assignment is a case of binding, but not the only one; two other examples are positional arguments in a function signature, and ESM imports. A binding can be mutable (let assignment, function arguments) or immutable (const assignment, ESM import). Value mutability is orthogonal. You can mutably bind a primitive value as "let a = 22" and then mutate the binding via reassignment, but you can't mutate the value itself; you can immutably bind a reference value as "const b = {}" and mutate the referenced object via property access, but you can't mutate the binding. I refer to bindings all the time, where it's useful to be clear in meaning. I also make sure to introduce the concept to mentees who aren't already familiar with it, and by all reports thus far it's proven as valuable an abstraction for them as it did for me when I first learned of it.
    - ricardobeat 3y ago
deleted 3y ago
[deleted]

arrowleaf 3y ago

The book is actually maintained on GitHub too, https://github.com/marijnh/Eloquent-JavaScript https://github.com/marijnh/Eloquent-JavaScript. When I was just starting out I read this book and noticed a small mistake, I was really proud that one of my first contributions to any open source project was a PR to this repo.

svat 3y ago
Thanks, that gives a way of seeing the diff between the third edition and the current (last commit 45 minutes ago): https://github.com/marijnh/Eloquent-JavaScript/compare/f8f004f..08cfb2a https://github.com/marijnh/Eloquent-JavaScript/compare/f8f00...

MikeTheGreat 3y ago

I'm curious - could you expand on why it's a pitfall to think of variables as boxes?

svat 3y ago
Because that's not how variables work in JavaScript/Python etc (though it may be fine for say C++ in the case of value types and copy constructors). For example: I'm typing on phone so for a quick example: let a = []; let b = a; a.push(1); and consider the value of b now (or the fact that we could write "const" above because the binding is constant, even though we mutate the value). Or see the equivalent for Python by Ned Batchelder, which has more examples and elaboration: https://nedbatchelder.com/text/names1.html https://nedbatchelder.com/text/names1.html
- MikeTheGreat 3y ago
  I knew that in Python all variables are really references to objects (even when we're using a number) - is JavaScript the same way? Also, does anyone have a link/reference to the place in the spec where it specifies this? I briefly skimmed through parts of [1] but couldn't find anything that says that JavaScript treats numbers this way. [1] https://tc39.es/ecma262/multipage/#sec-intro https://tc39.es/ecma262/multipage/#sec-intro
  - culturedsystems 3y ago
    I don't think there's an explicit reference in the JavaScript spec to numbers being treated this way, because this is how all variables are treated in JavaScript - the relevant part of the specification is probably the definition of the "PutValue" abstract operation[1], which doesn't include any special cases for numbers (or other primitive types) vs. objects. [1] https://tc39.es/ecma262/multipage/ecmascript-data-types-and-values.html#sec-putvalue https://tc39.es/ecma262/multipage/ecmascript-data-types-and-...
  - svat 3y ago
    As I understand it, JavaScript does have a distinction between the primitive types and Object, but this does not show up in any significant way to the programmer / in any way relevant to how to view variables. To put it differently, the "boxes" view only applies to primitive values, while the "tentacles" view applies to all values, so the former is unnecessary and need not even be considered/taught.