Hacker News new | ask | show | jobs
by catnaroek 3836 days ago
I have no idea what you mean by JavaScript being "easier" to learn than C++. My experience has been the exact opposite.

C++ is a giant beast, but most of it was relatively easy to learn after I internalized the general principles that guide the language's design. These principles were the first coherent account I ever found of how programs manipulating ephemeral resources should be written. [I am aware that Rust improves on C++, but it builds on, rather than replace, the general principles established by C++.]

On the other hand, in JavaScript I have never found anything even remotely close to methodological guidance for writing programs. JavaScript seems to make sense of anything as long as it is syntactically valid - a very low bar. As a result, I felt like I had to navigate a really huge space, hoping to eventually find a correct program somewhere.

JavaScript's ability to run in the browser is, as far as I can tell, its only advantage over C++.

1 comments

> I have no idea what you mean by JavaScript being "easier" to learn than C++. My experience has been the exact opposite.

You are a tiny minority in this. I've taught C++ and JS and have never once seen JS be harder to pick up.

> On the other hand, in JavaScript I have never found anything even remotely close to methodological guidance for writing programs.

The #1 selling JS book is (was) literally called "JavaScript: The Good Parts". It teaches "methodological guidance" for writing JavaScript programs. Just as modern C++ books teach the "good parts" of C++.

> JavaScript seems to make sense of anything as long as it is syntactically valid - a very low bar.

That's (a) not true, with the static resolution semantics in modules; (b) to the extent that it is true is mostly a criticism of dynamic typing, which has a lot of advantages and is not a criticism of JavaScript.

> JavaScript's ability to run in the browser is, as !far as I can tell, its only advantage over C++.

Memory safety? GC? A module system (as compared to #include)? Dynamic typing? This is silly.

(NB: I also think C++ has a lot of advantages over JS for certain domains. I'm a language pluralist.)

> The #1 selling JS book is (was) literally called "JavaScript: The Good Parts". It teaches "methodological guidance" for writing JavaScript programs. Just as modern C++ books teach the "good parts" of C++.

I'm talking about guidance from the language itself, not external parties. For instance, C++ templates don't provide such guidance - it's very difficult for C++ compilers to tell you where and how exactly you're using templates wrong. On the other hand, C++ destructors do provide such guidance - just put all your finalization logic in destructors and you're done.

> That's (a) not true, with the static resolution semantics in modules

Even with strict mode and statically resolved imports, JavaScript requires extremely defensive programming to get useful diagnostics when anything goes wrong beyond using identifiers not in scope.

> (b) to the extent that it is true is mostly a criticism of dynamic typing

Python (not to mention Scheme, which JavaScript is allegedly inspired by) is dynamically typed, but does a much better job of treating nonsensical code as an error.

> Memory safety? GC?

It's true that garbage collection makes memory management a non-problem in the vast majority of situations, but it doesn't even begin to address managing other resources. Unfortunately, a program whose only avilable resource is memory (and perhaps the standard streams) is nothing but a fancy calculator.

RAII is a comprehensive solution to a wide class of problems that includes memory management as a special case, so I think C++ wins this one.

> A module system (as compared to #include)?

Of course, you're completely right about this.

> Dynamic typing?

I can get exactly as much dynamic typing as I need in C++ programs, without affecting the parts that are meant to be statically typed.