5 ms·
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 NoMethod
by namelost 9y ago
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.
- SomeStupidPoint 9y agoSomeone 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.
- kbp 9y ago> 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.
- matt2000 9y agoI agree with everything you said, except for the part where you said JavaScript was "designed".
- wwwkeykey 9y agoLOL best comment :D
- deleted 9y ago[deleted]
- kccqzy 9y agoPlenty of languages designed before the 90s got this right. It's not like typing is a recent development.
- quickthrower2 9y agoHaskell was designed in the 90s. So don't blame the decade.