3 ms·

One problem here is that Javascript eats a lot of type errors silently. $ node > 1+[] '1' > 1-[] 1 > 1null 0 > 1undefined NaN > x = {}

One problem here is that Javascript eats a lot of type errors silently. $ node > 1+[] '1' > 1-[] 1 > 1*null 0 > 1*undefined NaN > x = {} {} > 1+x.a NaN This is not something that other dynamically typed languages necessarily do.

flavio81 9y ago
This is not something that other dynamically typed languages necessarily do Yes, I agree, and this is because Javascript is very weakly typed, and sadly, no tool like Typescript will go so far in counteracting this, because the runtime itself (JS) is still weakly typed. So... no real substitute for good old runtime testing, i'd say.
- neurotrace 9y ago
  Except that a strong static type system wouldn't allow you to write code like this in the first place. You wouldn't hit these issues at run-time because you caught them at compile-time.
  - mikewhy 9y ago
    Say you have an API endpoint: router.post('/users', (req, res) => { const body = req.body as MyEndpointInterface }) If someone posts to that endpoint with the wrong interface, you're still going to have problems. I'm not sure of any language that would catch such a thing at compile-time and not need some sort of test.
mazelife 9y ago
Before I even read the article, I wondered how may of the bugs detected would be due to JavaScript's implicit type coercion rather than specifically dynamic vs. static typing issues. Sadly the article doesn't seems to say, but I thought it telling that the one example they gave: function addNumbers(x, y) { return x + y } console.log(addNumbers(3, "0")) ...of a bug that type annotations can detect has nothing to do with dynamic typing! As you point out there are plenty of dynamically typed languages (e.g. Python) where this would raise an exception. Now you could make an argument that in a static vs. dynamic context yo'd be talking about a compile-time vs. a run-time error, but strictly speaking, the bug here (a function returning a nonsensical value) has nothing to do w/ the kind of type checking performed. Static/dynamic typing and strong/weak typing are orthogonal issues and it's a pet peeve of mind when people sort of muddle them together as they do in this article. FWIW, I think there are decent arguments to be made on both sides of static/dynamic divide, but weakly-typed languages have always just felt like a terrible idea to me that allows careless thinking about data types to creep in all to easily.

One problem here is that Javascript eats a lot of type errors silently. $ node > 1+[] '1' > 1-[] 1 > 1*null 0 > 1*undefined NaN > x = {}

flavio81 9y ago

This is not something that other dynamically typed languages necessarily do Yes, I agree, and this is because Javascript is very weakly typed, and sadly, no tool like Typescript will go so far in counteracting this, because the runtime itself (JS) is still weakly typed. So... no real substitute for good old runtime testing, i'd say.

neurotrace 9y ago
Except that a strong static type system wouldn't allow you to write code like this in the first place. You wouldn't hit these issues at run-time because you caught them at compile-time.
- mikewhy 9y ago
  Say you have an API endpoint: router.post('/users', (req, res) => { const body = req.body as MyEndpointInterface }) If someone posts to that endpoint with the wrong interface, you're still going to have problems. I'm not sure of any language that would catch such a thing at compile-time and not need some sort of test.

mazelife 9y ago

Before I even read the article, I wondered how may of the bugs detected would be due to JavaScript's implicit type coercion rather than specifically dynamic vs. static typing issues. Sadly the article doesn't seems to say, but I thought it telling that the one example they gave: function addNumbers(x, y) { return x + y } console.log(addNumbers(3, "0")) ...of a bug that type annotations can detect has nothing to do with dynamic typing! As you point out there are plenty of dynamically typed languages (e.g. Python) where this would raise an exception. Now you could make an argument that in a static vs. dynamic context yo'd be talking about a compile-time vs. a run-time error, but strictly speaking, the bug here (a function returning a nonsensical value) has nothing to do w/ the kind of type checking performed. Static/dynamic typing and strong/weak typing are orthogonal issues and it's a pet peeve of mind when people sort of muddle them together as they do in this article. FWIW, I think there are decent arguments to be made on both sides of static/dynamic divide, but weakly-typed languages have always just felt like a terrible idea to me that allows careless thinking about data types to creep in all to easily.