[whatsmyusername]

The worst part about javascript failing is a lot of time it doesn't do it at the thing that is the problem.

I've run into a lot of cases in node where I passed something not quite right to a crypt library but didn't find out until like 2 pages later. Usually for things that in python would throw an exception immediately.

[Jtsummers]

That's not really a Javascript problem. That's a dynamically typed language problem. Unless you add some kind of assertion/test at the entry point to a library, the failure will always be postponed to the point of use (or silent if it's never used, until the day someone turns a feature on). If the same sort of issue works differently in Python, the Python library has asserts or other tests, or is using the value at an earlier point so it's more easily discovered.

[dahfizz]

JavaScript is absolutely the problem.

As pointed out, {}.foo will not cause an error. In Python and any good dynamic language, that will generate an error.

Another problem is all the implicit (silent) type conversions. JavaScript will happily add an Object and an integer, then multiply that by a string. Any sensible type system would not allow that, but JavaScript silently produces a NaN.

The problem isn't that its a dynamic type system, but that the type system ignores things which are clearly problems.

[klyrs]

> That's not really a Javascript problem. That's a dynamically typed language problem.

I disagree; I do a lot of work in both dynamic and strongly typed languages. Most often, when I find a bug "not where the error occurs," it's because, for example, I'm accidentally computing a minimum and later assuming it to be a maximum. Unit tests catch most of this, so such debugging puzzles usually happen to me in fresh new code with unstable interfaces...

[jolux]

JavaScript does a lot more implicit coercions in bad ways than Python does.

[kerkeslager]

No, it's definitely a JavaScript problem. Dynamic languages like Python are perfectly capable of throwing exceptions when you reference a property that doesn't exist.

Failing silently makes sense in a language like C, where performance is a high priority and you can avoid adding assertions for performance. But JavaScript has to add an assertion to return an undefined value anyway, so you're not even getting a performance benefit from it. It's purely bad design with no benefit.

[wlesieutre]

Coming from python, my other least favorite javascript-ism is that you can call functions with the wrong number of parameters and it'll just set the missing ones as undefined and assume that's what you meant to do.

Maybe people who are used to js take advantage of this and do it on purpose, but from my perspective all it's done is take mistakes and move the errors farther downstream so that you can't trivially find where the problem started.

If I wanted a function to accept a variable number of parameters or have default values for a parameter that can be omitted, I would much rather have to have to define that behavior per function.

[anoncake]

It's a weakly typed language problem, static vs dynamic typing has nothing to do with it.