Hacker News Reader

Comment by jonpacker | Hacker News Reader

If you take an hour to sit down and understand the type coercion, all of these "hidden surprises" magically disappear.

1. Understanding JavaScript type coercion correctly, including (emphasizing!) all of the corner cases that actually matter, is not an hour's task.

2. The fact that pathological-condition-X of a language is in theory understandable with sufficient study is a total red herring in a broad discussion of that language.

Understanding all the corner cases of how C deals with integers is a huge undertaking, as the C Integer Quiz thread showed us. But in practice, it's not actually a problem since you just learn to avoid using features of the language that involve type coercion. Just simply don't mix types. only use === and !==, use a templating library instead of the + operator to construct strings. jslint can catch the rest. If you truly find the way javascript behaves surprising- in the sense that you are trying to do something reasonable, and it surprises you, I have to wonder what on earth you are trying to do that would invoke type coercion to begin with, and why you need to do it that way.

I think there is a bit of an issue with _the code you don't write_ , because you rely on third parties.

Today, I spent five minutes tracking down a

    SyntaxError: Unexpected token u

It was honestly hard to read this as "don't give an un-itialized value to this function or it will end up being passed to JSON.parse that will happily treat undefined as a string".

I'd take a NullPointerException with a proper stacktrace everyday.

in chrome, error objects have stack traces attached. All you would have needed to do is wrap the problem code in a try/catch, catch the error, and print out the stack trace, assuming you can't figure out how to find the stack trace just using chrome's web debugger. https://code.google.com/p/v8/wiki/JavaScriptStackTraceApi

You are missing my point, the issue is not that the error does not have a stacktrace, it's that it looks like:

    SyntaxError: Unexpected token u foo.js:123
    h foo.js:456
    g foo.js:789
    f

The issues are

* no reference to JSON.parse which is where the error occurred

* the error is not "object has no attribute toString", which would have made it clear what it's happening, but something else derived from having silently coerced "undefined" to string, which obscures what is happening.

As I wrote, it was a five minutes thing, not hours, but it's five minutes I would not have spent if it had been:

    TypeError: Cannot read property 'toString' of undefined: [native code]
    JSON.parse [native code]
    h foo.js:456
    g foo.js:789
    f

If parts of the language are so confusing that they should be avoided, arguably they should be removed completely.

They should, were it not for the backward compatibility requirement.

While I share your "just sit down and learn something instead of complaining" sentiment, in this case I think it's pretty difficult to memorize all the different ways that javascript does type coercion. Sure you get to know the most common pitfalls, but it just feels like even experienced JS programmers get bitten every now and then.

By now I'm sure everyone has seen the WAT talk (https://www.destroyallsoftware.com/talks/wat) which illustrates some of the more obscure (and funny) coercions.

It's ok to say that JS's type coercion is a misfeature, good programmers learn to not throw out the baby with the bathwater.

If you take [time-span] to understand the [x], all of these "hidden surprises" magically disappear.

Rewritten as a general programming language "smell". (That said, I do enjoy me some Javascripting, and I have a side-project with it.)

Reply on news.ycombinator.com