4 ms·

I think the thing most people are arguing with you about here is the distinction between, "it doesn't replace any tests" and "it doesn't replace all tests". Of

I think the thing most people are arguing with you about here is the distinction between, "it doesn't replace any tests" and "it doesn't replace all tests". Of course there will still be tests, but as other responses have been implying, there are entire classes of bugs that are runtime in Ruby and friends that are compile-time exceptions in other languages and those bugs would need to be weeded out in tests in Ruby, but they don't need to exist at all in other languages. And, there are huge qualities of life and developer velocity benefits to the statically typed languages due to those.

bazoom42 2y ago
As I already said, I’m a fan of static typing so you dont have to sell me on it. Static types are great for editor tooling, automated refactoring, documentation, catching trivial errors and typos as you type, and all-round sanity checking. I’m just pointing out that static typing does not replace any tests. At least not any test which a reasonable developer would write. What competent developer would write a test that only verifies that sqrt outputs a number, but not compare the output to an expected value? But such a strawman test is the only kind of test static typing would make obsolete.
- plorkyeran 2y ago
  If I write a sqrt function in a dynamically typed language, I will write a test which verifies that it does something reasonable when given something other than a number as input. I will not write that test in a statically typed language because it would not even be possible to write.
  - t-writescode 2y ago
    You also need to make sure to have at least 1 or 2 tests per instance where this function would be called remotely where you don't mock this function in remote calls, to make sure that the data types of the function aren't ignored, because the mock, since it doesn't have types either, might tolerate inputs to the function you didn't intend or have behavior you didn't intend if you refactor a type change.
  - bazoom42 2y ago
    What is “something reasonable”? In Pyhon you get a runtime error automatically if you perform an operation not supported by the object, e.g performing a mathematical operation on an object which is not number-like. This is out of the box behavior in a duck-typed language, just like a compile-time error is out of the box in a statically typed language. Of course you need to test for NaN, Infinity etc because these are number-like but still invalid. But you also need to do that in a statically typed language.

bazoom42 2y ago

As I already said, I’m a fan of static typing so you dont have to sell me on it. Static types are great for editor tooling, automated refactoring, documentation, catching trivial errors and typos as you type, and all-round sanity checking. I’m just pointing out that static typing does not replace any tests. At least not any test which a reasonable developer would write. What competent developer would write a test that only verifies that sqrt outputs a number, but not compare the output to an expected value? But such a strawman test is the only kind of test static typing would make obsolete.

plorkyeran 2y ago
If I write a sqrt function in a dynamically typed language, I will write a test which verifies that it does something reasonable when given something other than a number as input. I will not write that test in a statically typed language because it would not even be possible to write.
- t-writescode 2y ago
  You also need to make sure to have at least 1 or 2 tests per instance where this function would be called remotely where you don't mock this function in remote calls, to make sure that the data types of the function aren't ignored, because the mock, since it doesn't have types either, might tolerate inputs to the function you didn't intend or have behavior you didn't intend if you refactor a type change.
- bazoom42 2y ago
  What is “something reasonable”? In Pyhon you get a runtime error automatically if you perform an operation not supported by the object, e.g performing a mathematical operation on an object which is not number-like. This is out of the box behavior in a duck-typed language, just like a compile-time error is out of the box in a statically typed language. Of course you need to test for NaN, Infinity etc because these are number-like but still invalid. But you also need to do that in a statically typed language.