Eloquent JavaScript 4th edition (2024)

He did a day workshop at my old company about 10 years ago. He did come off as a dick, and very opinionated, but I really liked his no-stone-unturned approach, and ended up buying a few of the books when they came out later, and I got so much good stuff from reading them. I personally disagree with many of his opinions and have no problem with this at all; he covers everything (including parts of the language he clearly hates) in such detail that I can form my own dissenting opinions whenever I want. If anything, it’s a good thing that he is so openly opinionated - it makes it easier for me to pay attention and prompts me to ‘argue back’ and form my own (better) opinions, compared to just reading dry material that always tries to remain neutral and void of feeling. The only problem with opinionated code writers is if they actually fail to cover the stuff they don’t like. KS covers it all, with relish, often bitterly. I love it. Same for Doug Crockford. Always found him hilariously opinionated, often to the point that he was clearly fighting against reality, and yet I learned a ton by reading the cantankerous old git.

I know Kyle and he is very opinionated and adheres very tightly to his set of beliefs. I think this can rub some people the wrong way and maybe this leads to the belief that he is a dick.

From my personal experience I think he's actually a really nice guy. He's also been unemployed for quite a while now and seems to be struggling with something. Doesn't seem very kind to kick him while he's down even if it's a virtual kicking.

Went to JSConf India, specially for Kyle Simpson talk. His whole talk was just how his company can be a game changer for web development. Just so disappointing

I think Kyle Simpson is out of work and looking for something full-time and also started some other company, so probably not his main priority atm.

Why do you feel that way? What books would you recommend instead?

Are you reading programming books the same way you would read a fiction book? If so, stop doing that.

Programming or any technical learning is a hands on experience. Take notes and apply techniques, using pen-and-paper or the keyboard, as they are presented.

If you really have to just "read" a technical book, IME a less-is-more approach works best. 5-10 minutes at a time, not even a chapter at once. Maybe a few paragraphs if its something really information dense. Funny aside, I find my morning "business" is the perfect time to this sort of reading using the Kindle app on my phone.

What I like to do, when not under time pressure, is to read such a book cover-to-cover, as a first pass. I get an idea which parts will be difficult for me, and which are probably not.

In this stage, I don't sweat the parts I don't get, I just note for later, that, if these turn out to be important, will require some care, patience and time. I also build some sort of "map" in my mind about the elements that exist, to get an overview.

After doing so, I feel a lot more confident to tackle the topic of the book "properly", doing exercises, etc.

Take notes as you go or by chapter. If a chapter has a summary at the end, read that first before going through the chapter. If there are code examples, write them out and play around with it. Get the important bits out that way.

Also, realistically you probably won't remember most of what you read. I suck at that as well, but you do build up a lot of peripheral knowledge. You may not remember how to do that one thing, but maybe you do remember that it exists, or that it was in a particular book. Just that type of knowledge has worked well for me.

1. Take notes. If you are reading an ebook or a webpage, handwritten notes may be better because you will not be tempted to copy and paste.

2. If feasible for you, consider getting a neuropsychological evaluation to rule out any learning disabilities like adult attention deficit disorder.

Not the original poster, but I learn best reading textbooks cover-to-cover. A couple things that help me:

1) I buy physical textbooks and absolutely destroy them with notes in the margins, highlighting, etc. It helps me to interact with the material instead of letting it wash over me, which means I'm both thinking about it more in-depth and as side effect I'm less bored. Otherwise I'll fall asleep and won't learn anything. 2) I accept that I'm not going to remember the entire book. A lot of books are most useful as references anyway. But if you ever find yourself going, "Oh that's really handy to know," then you can make a special note of it or even put it into flashcards. I've been using Anki. The trick is to recognize what is actually worth doing this for. 3) If something is especially worth knowing, (see point 2), see if you can either do problems from the book or try out the concept in some way if there are no problems available.

If you're reading something just because you feel like you should, you won't get anything out of it (or a least I don't).

When reading a book, I don't do anything special, but I frequently stop and think about what I've just read. It's not something I do by a command, either: it's just that a good book engages my attention, and then I kind of "chew" on it.

Unlike others here, I never take notes, and rarely do suggested exercises. But I read and think through examples; and as to exercises, I do think of "how I would approach it" and "what is that the author wants me to learn from this exercise".

Spaced-repetition and active recall are underutilized tools that can increase your retention of material you deem worth remembering.

Here's an example of how to use it to learn quantum mechanics, but you can imagine how it would translate to technical books for software developers: https://www.youtube.com/watch?v=OFuu4pesKf0

That's how I learnt programming (self study) as a high schooler more than 2 decades ago: by studying books (affordable fast internet connection wasn't a thing at that time).

Start from chapter 1, study the concepts and play with the code examples a few times till you understand. Usually there are exercises at the end of each chapter. Try to work on those.

The Hard Parts of UI Development was amazing. Your teaching style really has a way of making things stick. Truly one of my favorite instructors.

In that sense an annotated "this is what JS used to be when this book first came out" version could be of historical interest.

Last time was 2017 I think, don't know if there is a big difference I use both new and old things

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.

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.

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

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.

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) 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.

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