Hacker News Reader

Comment by namelost | Hacker News Reader

It's not so much dynamic typing, but a lack of typing. Dynamic typing means that type checks are made at runtime.

e.g. in Ruby:

    irb> nil >= 0
    NoMethodError: undefined method `>=' for nil:NilClass

and Python 3:

    >>> None >= 0
    TypeError: '>=' not supported between instances of 'NoneType' and 'int'

Obviously JS (and Python 2!) get this wrong, but to be fair JS was designed in the 90s.

View on HN

Someone else pointed out that Java has (or had?) a similar issue with comparing boxed Ints -- equality checks for object level equality while inequality compares the values.

Without explicit casting, the equality operator casts to a more general type (or rather, doesn't cast at all) than the inequality operator (which casts to numerics).

This happens anywhere you have weird coercion rules.

> Java has (or had?) a similar issue with comparing boxed Ints -- equality checks for object level equality while inequality compares the values.

In Java 5 and up, 'new Integer(1) < new Integer(2)' will return true, because it automatically unboxes both Integers and compares them as primitives (before Java 5 it was a compile error).

It will not unbox the Integers in 'new Integer(1) == new Integer(1)', though, because given objects, '==' is always reference equality, so it will return false because they're different instances ('!=' would still return true, though). To compare objects by value, you use equals; 'new Integer(1).equals(new Integer(1))' is true.

I agree with everything you said, except for the part where you said JavaScript was "designed".

Haskell was designed in the 90s. So don't blame the decade.

Plenty of languages designed before the 90s got this right. It's not like typing is a recent development.

Reply on news.ycombinator.com