Hacker News Reader

Comment by shdon | Hacker News Reader

The original presentation was nicely done, but knowing how things work in JavaScript (even though I don't know Ruby) meant I didn't exactly have that WTF-experience. This article explains it nicely to those who had.

View on HN

I think this kind of misses the point. Even if you understand why JavaScript behaves this way, it doesn't mean that the behavior is sane.

JavaScript without type coercion would have been safer and saner in my opinion.

Type coertion is a language feature just like some other risky-yet-helpfull features. Take for example pointers: any programming language without pointer is safer†, but pointers help you express certain things concisely and thus avoid some classes of bugs. Heck, a knife with dull blade is safer just as well, but that doesn't increase its overall utility.

Compare with:

> UNIX was not designed to stop its users from doing stupid things, as that would also stop them from doing clever things. — Doug Gwyn

†except that you can generate NullPtrException in the pointerless Java. Ask yourself, WAT?

Nitpick: dull blades are not safer.

Sub-nitpick: Depends on how you're handling the blade.

A dull blade on a round onion is not safer than a sharp blade on that onion. Running your hand across a dull blade is safer than running your hand against a sharp blade.

Javascript in a nutshell.

Nitpick: Java does have pointers in the sense of indirect references, so it makes perfect sense that a NullPointerException can exist, even if having nullable references in general is a bad idea.

Java has references but not pointers, in that you can't do arithmetic with them. This actually does increase safety substantially; you can still get a (badly-named) exception by trying to dereference a null reference, but it's a lot harder to turn what was supposed to be a pointer to an input buffer into a pointer to your program's executable code.

Pointer are incredibly more useful than type coercion. In my experience, it is only really useful for beginners who then don't have to know that "1" and 1 are different things. JavaScript has a basically useless == operator because of this.

That's awfully generic and doesn't address the criticism. What are the examples of useful type coertion? What do they achieve? Are there no better ways to achieve those same goals without introducing bug-prone, WAT-inducing behaviors?

For example, string concatenation could have been handled by a separate operator.

To be fair, Eich was required to imitate java and finish in a couple of weeks for marketing reasons, and string + int -> string was one of java's mistakes.

Knowing C but not JavaScript, I can think of uses for all operations that are defined on C pointers. Yet, I cannot come up with one for String - Number or Hash + Array. If you want to argue that they are useful shortcuts, I think examples would help the case.

Well I think that was 'designed' basically to cast any type to it's string representation. Also wanted to point that I used type coercion when is supposed to be used, and never got a bug of that nature in my code, but yes, you must get the coercion rules right from the beginning, and yes, javascript code could live perfectly with this 'feature'.

Reply on news.ycombinator.com