6 ms·

Static typing is great for other reasons, but it doesn’t replace any tests. If you write a square root function, static typing can just ensure that it always r

Static typing is great for other reasons, but it doesn’t replace any tests. If you write a square root function, static typing can just ensure that it always returns a number which doesn’t tell you much. Unit tests can ensure it returns the correct number at least for some inputs. This is a lot more useful for ensuring correctness. The counter argument is that tests donsnt ensure the function always returns a number. Maybe it returns a date or a string for some particular input which is not covered by the test? While this is true, in my experience this is not a common problem.

mmcromp 2y ago
static typing doesn't cover all (or most) testing but it absolutely replaces type testing. webdev isn't square root functions it's working with complex data APIs. In fact, the argument was about ruby/rails not needing types/interfaces was because "the tests are the interface" that's how baked in tdd was
- kazinator 2y ago
  If I have a dynamically typed add function and I test that add(2, 2) produces 4, then the type testing is rolled right into it trivially. 4 has a type. If an object comes out of add(2, 2) that isn't an integer, then it won't match 4. Oftentimes, type is just a less specific match. It would be a waste of time to write a separate test case that add(2, 2) produces an integer, rather than just testing that it produces 4. I've hardly ever seen Lisp test cases that look only at the type of an output, rather than a specific value. Even a function whose job is to operate on types actually has inputs and outputs that are values representing types; e.g. the symbol string representing string types or whatever. However, there are tests which show that a function signals an error when given wrong types. Those would not be necessary in a static language; the function called with wrong types would not compile, and it goes without saying that all tests must compile, unless we are testing the compiler.
t-writescode 2y ago
> 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.
jim-jim-jim 2y ago
I'm not arguing against tests as much as I'm suggesting that sufficient typing can provide a similar form of interactive refactoring that the author claims TDD facilitates. Numerical functions are usually good candidates for tests. I don't even have an axe to grind about TDD itself. I don't do it and nobody forces me to. I'm just hypothesizing that the practice was tied to the primitive typing of its time. I could be wrong about this.
motorest 2y ago
> If you write a square root function, static typing can just ensure that it always returns a number which doesn’t tell you much. What does your square root function return if you feed it a string? And what does it return if you feed it a JSON object?
- bazoom42 2y ago
  If this is a strongly typed “duck typed” language, presumably it will throw an error when you apply some mathematical operation to a non-number value. If it is JavaScript you probably get NaN. If you have code which pass a json objects to a sqrt function then the calling code is in error so presumably tests for that code would flag it. Counter question: What happens in a statically typed language if you pass a negative number? I just tried in C# and surprise: NaN
  - motorest 2y ago
    > If this is a strongly typed “duck typed” language, presumably it will throw an error when you apply some mathematical operation to a non-number value. The value added by statically typed languages is that your runtime errors are instead compile time errors what are checked for free without having to add a single test.
    - bazoom42 2y ago
      You still need the tests to ensure the code is correct though. A sqrt function returning 27 for every input would be “proven correct” by static typing.
      - motorest 2y ago
        > You still need the tests to ensure the code is correct though. You do, but not the boilerplate stuff to check that your code throws a runtime error if you pass a JSON doc to a square root function. Having runtime errors instead of compile-time ones is also a major liability. > A sqrt function returning 27 for every input would be “proven correct” by static typing. That's not what's being argued.

mmcromp 2y ago

static typing doesn't cover all (or most) testing but it absolutely replaces type testing. webdev isn't square root functions it's working with complex data APIs. In fact, the argument was about ruby/rails not needing types/interfaces was because "the tests are the interface" that's how baked in tdd was

kazinator 2y ago
If I have a dynamically typed add function and I test that add(2, 2) produces 4, then the type testing is rolled right into it trivially. 4 has a type. If an object comes out of add(2, 2) that isn't an integer, then it won't match 4. Oftentimes, type is just a less specific match. It would be a waste of time to write a separate test case that add(2, 2) produces an integer, rather than just testing that it produces 4. I've hardly ever seen Lisp test cases that look only at the type of an output, rather than a specific value. Even a function whose job is to operate on types actually has inputs and outputs that are values representing types; e.g. the symbol string representing string types or whatever. However, there are tests which show that a function signals an error when given wrong types. Those would not be necessary in a static language; the function called with wrong types would not compile, and it goes without saying that all tests must compile, unless we are testing the compiler.

t-writescode 2y ago

> 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.

jim-jim-jim 2y ago

I'm not arguing against tests as much as I'm suggesting that sufficient typing can provide a similar form of interactive refactoring that the author claims TDD facilitates. Numerical functions are usually good candidates for tests. I don't even have an axe to grind about TDD itself. I don't do it and nobody forces me to. I'm just hypothesizing that the practice was tied to the primitive typing of its time. I could be wrong about this.

motorest 2y ago

> If you write a square root function, static typing can just ensure that it always returns a number which doesn’t tell you much. What does your square root function return if you feed it a string? And what does it return if you feed it a JSON object?

bazoom42 2y ago
If this is a strongly typed “duck typed” language, presumably it will throw an error when you apply some mathematical operation to a non-number value. If it is JavaScript you probably get NaN. If you have code which pass a json objects to a sqrt function then the calling code is in error so presumably tests for that code would flag it. Counter question: What happens in a statically typed language if you pass a negative number? I just tried in C# and surprise: NaN
- motorest 2y ago
  > If this is a strongly typed “duck typed” language, presumably it will throw an error when you apply some mathematical operation to a non-number value. The value added by statically typed languages is that your runtime errors are instead compile time errors what are checked for free without having to add a single test.
  - bazoom42 2y ago
    You still need the tests to ensure the code is correct though. A sqrt function returning 27 for every input would be “proven correct” by static typing.
    - motorest 2y ago
      > You still need the tests to ensure the code is correct though. You do, but not the boilerplate stuff to check that your code throws a runtime error if you pass a JSON doc to a square root function. Having runtime errors instead of compile-time ones is also a major liability. > A sqrt function returning 27 for every input would be “proven correct” by static typing. That's not what's being argued.