6 ms·

This is not exactly the point the article talks about, but it's irked me for quite some time. When you see the documentation for a library in a dynamic language

This is not exactly the point the article talks about, but it's irked me for quite some time. When you see the documentation for a library in a dynamic language, it looks the same as if the language was static: the class of all the arguments and what the functions return is specified. So in the end you end up using it just like you would a static language, but with all the type checks done at runtime instead of before. This doesn't make much sense if you want to avoid errors.

woah 11y ago
Sure, that's the common argument, but static languages often require a bunch of gymnastics to get the compiler to accept valid code. They have a lot of abstractions that are not even necessary in dynamic languages.
- rhaps0dy 11y ago
  The gymnastics part is correct. You have to convince the compiler the code you are producing is correct, even if it may be correct already. However, this makes your code way more unlikely to crash or be incorrect. The "lot of abstractions" is the distinction between type and class the article addresses, I guess?
- loup-vaillant 11y ago
  > static languages often require a bunch of gymnastics to get the compiler to accept valid code I'd rather do the gymnastic and have the compiler tell me where I screw up right away. That's a tighter, more accurate feedback loop than a REPL. (Source: trying to implement a simple depth first search in both Lua and Ocaml.)
  - dllthomas 11y ago
    And of course, you can still have the repl :D
- dragonwriter 11y ago
  > Sure, that's the common argument, but static languages often require a bunch of gymnastics to get the compiler to accept valid code. There's really two problems hidden in that that deserve to be considered: (1) Static languages with insufficiently-expressive type systems may require more complex code (in terms of actual operations, not just type declarations) for the code to be valid when compared to dynamic languages (or static languages with sufficiently-expressive type systems.), and (2) static languages may, depending on the situation and the completeness of their type inference system, require arcane incantations to the type system before it accepts that correct code is, in fact, correctly typed. Some statically-typed languages are good on one or both of these measures, and so make less of one or both types of problems (Haskell, IMO, is pretty good on both, as static languages go, but lots of more popular static languages are really bad at one or both.)
svachalek 11y ago
That's an overly broad generalization, and doesn't line up with my experience. For example I don't see much about "classes" in MDN: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/parseInt https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... https://developer.mozilla.org/en-US/docs/Web/API/Window/location https://developer.mozilla.org/en-US/docs/Web/API/Window/loca...
- jameshart 11y ago
  "Window.location returns a Location object" "you can also assign a DOMString to it" "The parseInt() function parses a string argument and returns an integer" "If string is not a string, then it is converted to one" Seems like this documentation talks about little else than types to me?
  - gorena 11y ago
    > "The parseInt() function parses a string argument and returns an integer" This seems... factually incorrect? Shouldn't it say "a double"? (or a "number", which just means "double" in JS) It might ignore any characters after a ".", but it's impossible to return an integer in JS...
    - chc 11y ago
      No, it returns an integer. ECMAScript doesn't officially have a distinct integer type, but the number returned will still be an integer. Incidentally, most JavaScript implementations actually do have an internal integer representation, even though typeof will still just say it's a number.
- rhaps0dy 11y ago
  string: The value to parse. If string is not a string, then it is converted to one [...] radix: An integer between [...] The Window.location read-only property returns a Location object You gave supporting evidence for my point.
- barsonme 11y ago
discreteevent 11y ago
"So in the end you end up using it just like you would a static language, but with all the type checks done at runtime instead of before" When I first worked on a JavaScript project I found that there were explicit unit tests that just checked for types. I wasn't expecting that. You have to write more code than in a statically typed codebase. Dynamically typed languages are not for lazy programmers!

woah 11y ago

Sure, that's the common argument, but static languages often require a bunch of gymnastics to get the compiler to accept valid code. They have a lot of abstractions that are not even necessary in dynamic languages.

rhaps0dy 11y ago
The gymnastics part is correct. You have to convince the compiler the code you are producing is correct, even if it may be correct already. However, this makes your code way more unlikely to crash or be incorrect. The "lot of abstractions" is the distinction between type and class the article addresses, I guess?
loup-vaillant 11y ago
> static languages often require a bunch of gymnastics to get the compiler to accept valid code I'd rather do the gymnastic and have the compiler tell me where I screw up right away. That's a tighter, more accurate feedback loop than a REPL. (Source: trying to implement a simple depth first search in both Lua and Ocaml.)
- dllthomas 11y ago
  And of course, you can still have the repl :D
dragonwriter 11y ago
> Sure, that's the common argument, but static languages often require a bunch of gymnastics to get the compiler to accept valid code. There's really two problems hidden in that that deserve to be considered: (1) Static languages with insufficiently-expressive type systems may require more complex code (in terms of actual operations, not just type declarations) for the code to be valid when compared to dynamic languages (or static languages with sufficiently-expressive type systems.), and (2) static languages may, depending on the situation and the completeness of their type inference system, require arcane incantations to the type system before it accepts that correct code is, in fact, correctly typed. Some statically-typed languages are good on one or both of these measures, and so make less of one or both types of problems (Haskell, IMO, is pretty good on both, as static languages go, but lots of more popular static languages are really bad at one or both.)

svachalek 11y ago

That's an overly broad generalization, and doesn't line up with my experience. For example I don't see much about "classes" in MDN: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/parseInt https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... https://developer.mozilla.org/en-US/docs/Web/API/Window/location https://developer.mozilla.org/en-US/docs/Web/API/Window/loca...

jameshart 11y ago
"Window.location returns a Location object" "you can also assign a DOMString to it" "The parseInt() function parses a string argument and returns an integer" "If string is not a string, then it is converted to one" Seems like this documentation talks about little else than types to me?
- gorena 11y ago
  > "The parseInt() function parses a string argument and returns an integer" This seems... factually incorrect? Shouldn't it say "a double"? (or a "number", which just means "double" in JS) It might ignore any characters after a ".", but it's impossible to return an integer in JS...
  - chc 11y ago
    No, it returns an integer. ECMAScript doesn't officially have a distinct integer type, but the number returned will still be an integer. Incidentally, most JavaScript implementations actually do have an internal integer representation, even though typeof will still just say it's a number.
rhaps0dy 11y ago
string: The value to parse. If string is not a string, then it is converted to one [...] radix: An integer between [...] The Window.location read-only property returns a Location object You gave supporting evidence for my point.
barsonme 11y ago

discreteevent 11y ago

"So in the end you end up using it just like you would a static language, but with all the type checks done at runtime instead of before" When I first worked on a JavaScript project I found that there were explicit unit tests that just checked for types. I wasn't expecting that. You have to write more code than in a statically typed codebase. Dynamically typed languages are not for lazy programmers!