3 ms·

> but it doesn’t replace any tests. As someone who has programmed in statically-typed languages and ones that aren't, I can absolutely, positively confirm that

> but it doesn’t replace any tests. As someone who has programmed in statically-typed languages and ones that aren't, I can absolutely, positively confirm that a static typing system and compile-time checks absolutely, positively replace an enormous swath of tests. The difference between refactoring code in Ruby and in Kotlin (or Java or C# or whatever other language you choose) is worlds apart when you can actually trust that the thing being sent to the method you're checking actually conforms to a certain type. What would take multiple days and maybe weeks to find all the edge-case-hells of type assumptions in Ruby is often a multiple-minutes change in those other languages.

rvz 2y ago
This. Unfortunately, this industry (especially startups) embraced the low-end of several untyped programming languages that are used in production-grade systems and evidently there's a price being paid by those choices. Java, Kotlin or even C# would be a much saner list of statically typed languages to use and testing code written in those languages is much easier to reason with.
bazoom42 2y ago
If you wrote a test which only checked that sqrt returned a number (any number) for a given input, then that test would indeed be superflous with static typing. But my argument is you would not write such a test in the first place. You would write a test which checks the output is correct which obviously implies it is also a number. Static typing does not in itself check if the output is correct, so you still need the test.
- t-writescode 2y ago
  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.

rvz 2y ago

This. Unfortunately, this industry (especially startups) embraced the low-end of several untyped programming languages that are used in production-grade systems and evidently there's a price being paid by those choices. Java, Kotlin or even C# would be a much saner list of statically typed languages to use and testing code written in those languages is much easier to reason with.

bazoom42 2y ago

If you wrote a test which only checked that sqrt returned a number (any number) for a given input, then that test would indeed be superflous with static typing. But my argument is you would not write such a test in the first place. You would write a test which checks the output is correct which obviously implies it is also a number. Static typing does not in itself check if the output is correct, so you still need the test.

t-writescode 2y ago
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.