5 ms·

Dynamic typing is a nightmare.

by infogulch 9y ago

gruez 9y ago
Done right (like in python), it's not so bad.
- zzalpha 9y ago
  I really wish the industry settled on terms for this stuff but alas... The difference is python is strict about its types and doesn't do automatic coercion. So at least you get type errors at runtime and not magic implicit behaviour. That said, even Perl did this better (less magic and surprises)... JavaScript is like a language intentionally designed to surprise the developer. Half the time I feel like it's a practical joke that someone accidentally took seriously.
  - alangpierce 9y ago
    > I really wish the industry settled on terms for this stuff I've pretty consistently heard "strong typing" to mean that the language avoids coercing between types, and "static typing" to mean that types are known at compile time. So JS and Python are both dynamic typed, but Python is (more) strongly typed and JS is (more) weakly typed. https://stackoverflow.com/questions/2690544/what-is-the-difference-between-a-strongly-typed-language-and-a-statically-typed https://stackoverflow.com/questions/2690544/what-is-the-diff...
    - mikebenfield 9y ago
      Yes, I've always understood this to be the correct terminology, but unfortunately in informal discussion among non-academically inclined software people, people use the terms wrong more often than they use them right. You get lots of people saying C is strongly typed (it certainly is not) and something like Scheme is weakly typed (it certainly is not).
      - zzalpha 9y ago
        If you're really want a fun time, try having a conversation about "duck typing" some time... it was around the time that term became a thing that I realized no one seems to agree on what all these terms mean.
  - marcosdumay 9y ago
    Using "strict" vs. "non-strict" and "static" vs. "dynamic" will increase a lot the odds of people understanding.
- TheRealPomax 9y ago
  the problem is there is no "right" until you define what right means, which is where the spec comes in. These results are "right", if unexpected, and the true issue here is of course not so much the mathematical results between the three tests, but the fact that JS gives you the freedom to compare anything to anything, irrespective of whether that comparison makes sense at all. Python allows this in a few places, too, with equally bizarre results (see another comment that highlights a few of them). While tempting to do so, thinking of >= as implying "> or ==" is simply not true in any language that performs type coercion to get around type incompatibility issues.
Pxtl 9y ago
While I dislike dynamic typing in general, in this case the nightmare comes from aggressive and inconsistent coercions. You could have the same mayhem in a statically-typed language with poorly-considered implicit typecasts.
outoftacos 9y ago
Yes I can contrive examples in any language that are nightmarish. Fortunately we manage to muddle through somehow, at least those of us who have work to do in lieu of walking through trivia to prove how smart we are to other hackers.
- zzalpha 9y ago
  Okay. Find an equivalently surprising example in... Let's use the other poster's choice, python. I'll wait. Edit: didn't have to wait long, way to go Python! Maybe I'll just claim it probably has fewer of these types of bizarre idiosyncrasies? I hope it has fewer... I'm always baffled by JavaScript apologists... Look, your baby is ugly. We know it's ugly. You know it's ugly. But if we point out the problems, hey, maybe the ECMA will update the language to fix some of the issues. Meanwhile, being aware of them is often important in order to build correct, secure code. And they're just entertaining. So chill. Let's all laugh at how ugly JS is on a Saturday morning and enjoy ourselves a bit. Because when it comes to the JS ecosystem, if we can't laugh, we'd probably be crying...
  - alangpierce 9y ago
    I gave a talk on Python idiosyncrasies a while back that you might enjoy: https://speakerdeck.com/alangpierce/python-puzzlers https://speakerdeck.com/alangpierce/python-puzzlers Several of the examples from that talk have equivalents in JavaScript where JavaScript does better. I think pretty much any real-world language has lots of surprises like this that you need to get used to, although I certainly admit JavaScript (particularly JS type coercion) tends to have especially surprising behavior.
    - zzalpha 9y ago
      I'd say JSs biggest problem is that the surprising behaviours aren't mostly sitting in dark corners waiting to bite you. They're standing there in the open, where everyone is likely to encounter them.
  - carussell 9y ago
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 ago
  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.
  - 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 ago
  I agree with everything you said, except for the part where you said JavaScript was "designed".
  - wwwkeykey 9y ago
    LOL best comment :D
  - deleted 9y ago
ratboy666 9y ago
No. In SNOBOL4 (one of the first dynamic typing languages) -- ident(x) yields true if x is "null", eq(x) is true if x is 0, gt(x) is ">" and ge(x) is ">=". The program "code" is a repl. Notice -- free format dynamic typing, and, it gets it "right". This language/run-time was originally from the late '60s, last official update in 1975 (with some updates in the intervening decades). Yes, according to the Javascript spec, the JS behaviour is correct. However, something as old as SNOBOL4 should have taught us that keeping type converting numerical operators dis-similar from object comparision would be good: "==" and "===" vs ident() and eq() and then relating ge() le() etc to the numeric class of operations consistently. : fred@dejah wittgenstein $; code The Macro Implementation of SNOBOL4 in C (CSNOBOL4BX) Version 2.0 by Philip L. Budne, January 1, 2015 SNOBOL4 (Version 3.11, May 19, 1975) BLOCKS (Version 1.10, April 1, 1973) Bell Telephone Laboratories, Incorporated EXTENSIONS (Version 0.25, June 16, 2015) Fred Weigel No errors detected in source program CODE (TUE AUG 4 10:28:58 EDT 2015) RUNNING ON CSNOBOL4 MAINBOL WITH SPITBOL, BLOCKS, EXTENSIONS ENTER SNOBOL4 STATEMENTS (TRY ? FOR HELP) 5,541,616 BYTES FREE CODE: ident() SUCCESS CODE: ident(0) FAILURE CODE: eq(0) SUCCESS CODE: eq() SUCCESS CODE: gt() FAILURE CODE: ge() SUCCESS CODE:quit Normal termination at level 1 code.lss:660: Last statement executed was 938 SNOBOL4 statistics summary- 5.384 ms. Compilation time 90.585 ms. Execution time 20577 Statements executed, 121 failed 20004 Arithmetic operations performed 122 Pattern matches performed 2 Regenerations of dynamic storage 29.481 ms. Execution time in GC 0 Reads performed 10 Writes performed 4402.237 ns. Average per statement executed 227.157 Thousand statements per second : fred@dejah wittgenstein $; and, keeping in the spirit: CODE: ge('a') EXECUTION ERROR #1, Illegal data type FAILURE Allow the explicit capture of "type" errors. We knew this in 1975. Why was this forgotten?
- laichzeit0 9y ago
  Lack of formal training in Computer Science. Most programmers are self-taught and know nothing about the history of the field or prior work.

Dynamic typing is a nightmare.

gruez 9y ago

Done right (like in python), it's not so bad.

zzalpha 9y ago
I really wish the industry settled on terms for this stuff but alas... The difference is python is strict about its types and doesn't do automatic coercion. So at least you get type errors at runtime and not magic implicit behaviour. That said, even Perl did this better (less magic and surprises)... JavaScript is like a language intentionally designed to surprise the developer. Half the time I feel like it's a practical joke that someone accidentally took seriously.
- alangpierce 9y ago
  > I really wish the industry settled on terms for this stuff I've pretty consistently heard "strong typing" to mean that the language avoids coercing between types, and "static typing" to mean that types are known at compile time. So JS and Python are both dynamic typed, but Python is (more) strongly typed and JS is (more) weakly typed. https://stackoverflow.com/questions/2690544/what-is-the-difference-between-a-strongly-typed-language-and-a-statically-typed https://stackoverflow.com/questions/2690544/what-is-the-diff...
  - mikebenfield 9y ago
    Yes, I've always understood this to be the correct terminology, but unfortunately in informal discussion among non-academically inclined software people, people use the terms wrong more often than they use them right. You get lots of people saying C is strongly typed (it certainly is not) and something like Scheme is weakly typed (it certainly is not).
    - zzalpha 9y ago
      If you're really want a fun time, try having a conversation about "duck typing" some time... it was around the time that term became a thing that I realized no one seems to agree on what all these terms mean.
- marcosdumay 9y ago
  Using "strict" vs. "non-strict" and "static" vs. "dynamic" will increase a lot the odds of people understanding.
TheRealPomax 9y ago
the problem is there is no "right" until you define what right means, which is where the spec comes in. These results are "right", if unexpected, and the true issue here is of course not so much the mathematical results between the three tests, but the fact that JS gives you the freedom to compare anything to anything, irrespective of whether that comparison makes sense at all. Python allows this in a few places, too, with equally bizarre results (see another comment that highlights a few of them). While tempting to do so, thinking of >= as implying "> or ==" is simply not true in any language that performs type coercion to get around type incompatibility issues.

Pxtl 9y ago

While I dislike dynamic typing in general, in this case the nightmare comes from aggressive and inconsistent coercions. You could have the same mayhem in a statically-typed language with poorly-considered implicit typecasts.

outoftacos 9y ago

Yes I can contrive examples in any language that are nightmarish. Fortunately we manage to muddle through somehow, at least those of us who have work to do in lieu of walking through trivia to prove how smart we are to other hackers.

zzalpha 9y ago
Okay. Find an equivalently surprising example in... Let's use the other poster's choice, python. I'll wait. Edit: didn't have to wait long, way to go Python! Maybe I'll just claim it probably has fewer of these types of bizarre idiosyncrasies? I hope it has fewer... I'm always baffled by JavaScript apologists... Look, your baby is ugly. We know it's ugly. You know it's ugly. But if we point out the problems, hey, maybe the ECMA will update the language to fix some of the issues. Meanwhile, being aware of them is often important in order to build correct, secure code. And they're just entertaining. So chill. Let's all laugh at how ugly JS is on a Saturday morning and enjoy ourselves a bit. Because when it comes to the JS ecosystem, if we can't laugh, we'd probably be crying...
- alangpierce 9y ago
  I gave a talk on Python idiosyncrasies a while back that you might enjoy: https://speakerdeck.com/alangpierce/python-puzzlers https://speakerdeck.com/alangpierce/python-puzzlers Several of the examples from that talk have equivalents in JavaScript where JavaScript does better. I think pretty much any real-world language has lots of surprises like this that you need to get used to, although I certainly admit JavaScript (particularly JS type coercion) tends to have especially surprising behavior.
  - zzalpha 9y ago
    I'd say JSs biggest problem is that the surprising behaviours aren't mostly sitting in dark corners waiting to bite you. They're standing there in the open, where everyone is likely to encounter them.
- carussell 9y ago

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 ago
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.
- 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 ago
I agree with everything you said, except for the part where you said JavaScript was "designed".
- wwwkeykey 9y ago
  LOL best comment :D
- deleted 9y ago

ratboy666 9y ago

No. In SNOBOL4 (one of the first dynamic typing languages) -- ident(x) yields true if x is "null", eq(x) is true if x is 0, gt(x) is ">" and ge(x) is ">=". The program "code" is a repl. Notice -- free format dynamic typing, and, it gets it "right". This language/run-time was originally from the late '60s, last official update in 1975 (with some updates in the intervening decades). Yes, according to the Javascript spec, the JS behaviour is correct. However, something as old as SNOBOL4 should have taught us that keeping type converting numerical operators dis-similar from object comparision would be good: "==" and "===" vs ident() and eq() and then relating ge() le() etc to the numeric class of operations consistently. : fred@dejah wittgenstein $; code The Macro Implementation of SNOBOL4 in C (CSNOBOL4BX) Version 2.0 by Philip L. Budne, January 1, 2015 SNOBOL4 (Version 3.11, May 19, 1975) BLOCKS (Version 1.10, April 1, 1973) Bell Telephone Laboratories, Incorporated EXTENSIONS (Version 0.25, June 16, 2015) Fred Weigel No errors detected in source program CODE (TUE AUG 4 10:28:58 EDT 2015) RUNNING ON CSNOBOL4 MAINBOL WITH SPITBOL, BLOCKS, EXTENSIONS ENTER SNOBOL4 STATEMENTS (TRY ? FOR HELP) 5,541,616 BYTES FREE CODE: ident() SUCCESS CODE: ident(0) FAILURE CODE: eq(0) SUCCESS CODE: eq() SUCCESS CODE: gt() FAILURE CODE: ge() SUCCESS CODE:quit Normal termination at level 1 code.lss:660: Last statement executed was 938 SNOBOL4 statistics summary- 5.384 ms. Compilation time 90.585 ms. Execution time 20577 Statements executed, 121 failed 20004 Arithmetic operations performed 122 Pattern matches performed 2 Regenerations of dynamic storage 29.481 ms. Execution time in GC 0 Reads performed 10 Writes performed 4402.237 ns. Average per statement executed 227.157 Thousand statements per second : fred@dejah wittgenstein $; and, keeping in the spirit: CODE: ge('a') EXECUTION ERROR #1, Illegal data type FAILURE Allow the explicit capture of "type" errors. We knew this in 1975. Why was this forgotten?

laichzeit0 9y ago
Lack of formal training in Computer Science. Most programmers are self-taught and know nothing about the history of the field or prior work.