Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Eloquent JavaScript 4th edition (2024)

eloquentjavascript.net

Post reply on HN
Print view View original

121–130 of 249 posts

Re: Eloquent JavaScript 4th edition (2024)

#121

Post by Exoristos »

ravenstine wrote: post #92

I don't mean to throw shade on the whole book, but I don't think the section on errors takes things in the right direction. A distinction should be made between errors and exceptions. In JavaScript and many languages, we conflate the two and use exception handling as logic flow control. In my experience, this can end up being a headache and encourage unnecessarily weird structuring of code. Look at this example from…

1. Exceptions can have codes, too, you know, and often do. 2. In the example, the exception is meant to bubble up all the way to the consumer. Different consumers can then handle as they see fit, even just displaying the exception message to the user.

Re: Eloquent JavaScript 4th edition (2024)

#122

Post by wk_end »

diggan wrote: post #48
wk_end wrote: post #36

Earlier quoted context omitted.

TypeScript isn't really a "compile-to-JavaScript" language in the same way that, say, Rescript is. Modulo a few corner cases (e.g. enums) which are now considered anti-features, TypeScript has the exact same runtime semantics as JavaScript - you can (almost) convert TypeScript to JavaScript just by stripping away the type annotations (and, if various ECMAScript proposals go through, you won't even need to do even tha…

I guess by that same definition, Coffeescript isn't a compile-to-JavaScript language either, as it has the same semantics as vanilla JavaScript? I think that's besides the point. My point was more that people who are supposed to learn JavaScript, should do so by learning vanilla JavaScript first, then they can move on to learning whatever is currently hyped by the zeitgeist (which happens to be TypeScript currently).

No, CoffeeScript doesn't have the same semantics as vanilla JavaScript; not in any meaningful sense I can think of, certainly not in the way that TypeScript does.

Most CoffeeScript will simply syntax error if you feed it into a JS interpreter (and vice versa), and there's no trivial syntactic transform to get around that (i.e. it's not just a new surface syntax over JavaScript). Various features in CoffeeScript have no equivalent in JS, so new code needs to be synthesized for them; even fundamental features that are shared by the two languages are different - for just one example, this [0] article shows that how a function is compiled in CoffeeScript is non-local - the compiler is tracking variable scopes to get around the fact that CoffeeScript and JavaScript have different scoping semantics.

With TypeScript, the "compilation" process is (almost):

  parse(typeScriptCode) -> treeMap(removeTypeAnnotation) -> write
That's it! TypeScript code is syntactically valid JavaScript code, just with added type annotations (and, as mentioned, soon that'll still count as syntactically valid JavaScript code); JavaScript code is syntactically valid TypeScript code without any type annotations - which doesn't make it syntactically invalid! Indeed, if you turn down the strictness settings on tsc to permit untyped code, the compiler doesn't even complain about it.

[0] https://donatstudios.com/CoffeeScript-Madness

Re: Eloquent JavaScript 4th edition (2024)

#123

Post by epolanski »

whiterknight wrote: post #40
epolanski wrote: post #34

Earlier quoted context omitted.

Not sure how's that relevant. Any valid JavaScript is valid TypeScript and you're gonna write and read TS anyway in the industry. They aren't in competition, but coming back to the first comment it sounds reasonable to start directly with TS for many users.

Your experience is not the industry. JS is widely used, almost certainly more than TS.

My experience may not, but the annual JS dev survey points that TS is the main way to write JS from years.

Re: Eloquent JavaScript 4th edition (2024)

#124

Post by wk_end »

Solvency wrote: post #52
wk_end wrote: post #36

Earlier quoted context omitted.

TypeScript isn't really a "compile-to-JavaScript" language in the same way that, say, Rescript is. Modulo a few corner cases (e.g. enums) which are now considered anti-features, TypeScript has the exact same runtime semantics as JavaScript - you can (almost) convert TypeScript to JavaScript just by stripping away the type annotations (and, if various ECMAScript proposals go through, you won't even need to do even tha…

Which further exposes the irony of casual hipsters who say things to me like "Thank God for Typescript, it's like a whole other language than JS". For example, a designer, who writes a quick one off plug-in for Figma in Typescript without realizing 99.9% could have been just written/pasted into the JS file (which is ultimately what Figma runs).

To be honest, in the appropriate context I will contradict myself and say that that you should think of TypeScript as a separate language. There's a lot of dynamic things you can do in JavaScript that will interact poorly with attempts to statically reason about your code with TypeScript; even if it's the approach you'd take in JS, when you add typing you should recalibrate how you approach the problem - that, to me, is an argument for thinking of it as separate language.

...but that's mostly just what I say to JavaScript devs, to be polite - to not tell them that their JavaScript code is bad, too. Code that's difficult to reason about statically is strictly worse, in my opinion, than code that's easier to reason about statically. And in that sense, TypeScript is just guiding you to write better JavaScript, which maybe undercuts its claim to being a language of its own.

Re: Eloquent JavaScript 4th edition (2024)

#125

Post by deprecative »

kabes wrote: post #90
samtho wrote: post #38

This is, in my opinion, the book to use to learn JavaScript at more than a surface level. The only other materials I recommend as much (but for a different level of learner) are the “You don’t know JavaScript” in-depth book series. In 2015, I was consulting for a distance learning program, administered by a major California University, that wanted to replace their current textbook (one of those “Head First” O’Reilly…

+1 for "You don't know js", it's a must read for any js programmer IMO. I haven't read eloquent JS though, you say it's a different level of learner. Can you expand a bit? Is Eloquent for after "you don't know js" or vice-versa? Edit: nevermind, reading the TOC of eloquent JS gave me a good enough idea

I get so jealous that people can absorb information via books as an adult. I can read the same chapter a hundred times and nothing sinks in.

I know this is off topic but do you, or anyone passing, have a system or tips for how y'all do this? I've got so many programming books but they only collect dust after I read through them without benefit.

Re: Eloquent JavaScript 4th edition (2024)

#127

Post by nestes »

deprecative wrote: post #125
kabes wrote: post #90

Earlier quoted context omitted.

+1 for "You don't know js", it's a must read for any js programmer IMO. I haven't read eloquent JS though, you say it's a different level of learner. Can you expand a bit? Is Eloquent for after "you don't know js" or vice-versa? Edit: nevermind, reading the TOC of eloquent JS gave me a good enough idea

I get so jealous that people can absorb information via books as an adult. I can read the same chapter a hundred times and nothing sinks in. I know this is off topic but do you, or anyone passing, have a system or tips for how y'all do this? I've got so many programming books but they only collect dust after I read through them without benefit.

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

Re: Eloquent JavaScript 4th edition (2024)

#128

Post by dr_kiszonka »

deprecative wrote: post #125
kabes wrote: post #90

Earlier quoted context omitted.

+1 for "You don't know js", it's a must read for any js programmer IMO. I haven't read eloquent JS though, you say it's a different level of learner. Can you expand a bit? Is Eloquent for after "you don't know js" or vice-versa? Edit: nevermind, reading the TOC of eloquent JS gave me a good enough idea

I get so jealous that people can absorb information via books as an adult. I can read the same chapter a hundred times and nothing sinks in. I know this is off topic but do you, or anyone passing, have a system or tips for how y'all do this? I've got so many programming books but they only collect dust after I read through them without benefit.

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.

Re: Eloquent JavaScript 4th edition (2024)

#129

Post by redbell »

samtho wrote: post #38

This is, in my opinion, the book to use to learn JavaScript at more than a surface level. The only other materials I recommend as much (but for a different level of learner) are the “You don’t know JavaScript” in-depth book series. In 2015, I was consulting for a distance learning program, administered by a major California University, that wanted to replace their current textbook (one of those “Head First” O’Reilly…

I second JavaScriptInfo as another great resource to learn JS: https://javascript.info/

Re: Eloquent JavaScript 4th edition (2024)

#130

Post by DarkNova6 »

Shog9 wrote: post #91
DarkNova6 wrote: post #70

Earlier quoted context omitted.

If you are in a completely self-defined world, then yes you can trust the compiler. But I once built a react component which was called from library code and it simply did not adhere to the method signature (this was for a material UI table extension). As soon as you have third party code calling your methods all bets are off. It could be JS calling your methods, or there simply is a hidden cast somewhere. This is th…

TBF, this can also be true in C++, C#, probably most languages that can interoperate with other systems not written 100% in the same language + same runtime. After a while, you just get used to not trusting anything at the boundary - types are for your convenience and your internal logic, nothing more.

You are talking about something entirely different. Having weird interop is one thing. But having your internal state compromised because the language does not perform runtime checks is something entirely different.

In case of C++ this would lead to desastrous memory corruption. If all data is dynamic you can't have a safe program as data on the stack must be monomorphic or you corrupt nearby memory.

Naturally, you can defend against hostile input via excessive defensive programming (asserting against nulls, asserting against wrong types etc.). Or you simply use a strong static typed language.

Post reply on HN