5 ms·

I don't think it really matters. Major bugs are not "oh this can be null", major bugs are "this combination of preconditions yield a business logic edge case th

I don't think it really matters. Major bugs are not "oh this can be null", major bugs are "this combination of preconditions yield a business logic edge case that wasn't accounted for". Static typing doesn't really help more than dynamic typing in these cases.

throwaway290 3y ago
It matters enough that the question "does static typing dramatically reduce the benefits of unit testing" is an open question or at least seriously discussed in the industry. All other replies are about dynamic languages.
- ska 3y ago
  I don't think it is really unresolved. Static languages with sufficiently rich and modifiable type systems avoid a fraction of cases where you may well want a unit test, but it's not the overwhelming majority. Merely static helps too but not all that much. So while there is a reduction, it's a stretch to call it "dramatic".
  - throwaway290 3y ago
    > I don't think it is really unresolved Well, you are currently participating in a thread that discusses this very question so there's that... and such threads are regular on HN. I meant just that. People discuss it. What you want to say is that you have a strong opinion about it, that's OK and still possible with open questions
    - ska 3y ago
      People discuss lots of things that are pretty well solved; i wouldn't equate "open question" with "lots of discussion". I guess in this context I mean that the question of static vs. dynamic in unit testing turns out to not be that hard, but the questions like "what is a unit test" and "should we unit test at all" are much muddier. Because people are confused or argumentative about the latter, they tend to pull the former into discussions that don't really have much to do with static vs. dynamic.
      - deleted 3y ago
        [deleted]
- pfdietz 3y ago
  Why isn't the question "does adequate testing dramatically reduce the benefits of static typing" asked? Why is static typing privileged by default?
  - tshaddox 3y ago
    Probably because using a static type system gives you those benefits "for free," whereas unit tests are things you need to write and maintain. ("For free" in scare quotes because of course there are always tradeoffs between different programming languages.)
    - pfdietz 3y ago
      The counterargument is that for sufficiently reliable software extensive testing is needed anyway, and if you do that you find the type errors "for free". If the testing is insufficient, as in practice it often surely is, then static typing would seem to be more valuable.
  - peterfirefly 3y ago
    It is asked. A lot.
  - mayoff 3y ago
    I wouldn’t say static typing is privileged, but that testing is disadvantaged, because, in the words of Edsger Dijkstra, “Program testing can be used to show the presence of bugs, but never to show their absence!” https://www.cs.utexas.edu/users/EWD/transcriptions/EWD02xx/EWD249/EWD249.html https://www.cs.utexas.edu/users/EWD/transcriptions/EWD02xx/E...
    - funcDropShadow 3y ago
      We could paraphrase Dijkstra --- with some liberty -- to say, "Formal verification of programs can only show the specification is fulfilled, not that the specification is adequate."
  - throwaway2037 3y ago
- randomdata 3y ago
  A fully evolved type system (e.g. Coq) overlaps with unit testing. But the vast majority of languages people actually use have only partial type systems that require unit tests to stand in where the type system is lacking. In practice, when you write those tests for where the type system is lacking, you end up also incidentally testing where there is type system coverage, so there likely isn't much for industry to talk about.
- kibwen 3y ago
  Having static types is like having an automatic, exhaustively comprehensive, efficient unit test generator for the classes of bugs whose units tests are the most boring and annoying to write and maintain. Static types don't prevent you from needing unit tests, they free you up to focus on writing tests that are actually interesting.
  - deleted 3y ago
    [deleted]
  - throwaway2037 3y ago
    I agree with your post. To be more specific, you can focus more on logic and state bugs.
  - throwaway290 3y ago
    This, but depending on how good the type system is and how well it's used most remaining interesting tests may be integration aside from legit things like https://news.ycombinator.com/item?id=38692634 https://news.ycombinator.com/item?id=38692634
- noselasd 3y ago
  I'm writing unit tests in rust and c++, I'm in the same boat as the op, often finding logical errors while writing the tests. Not to mention peace of mind when you go and mess around with code you wrote 9 months ago - if you mess up or didn't think of a corner case, there's decent chance it'll get caught by existing tests.
_dain_ 3y ago
>"this combination of preconditions yield a business logic edge case that wasn't accounted for". Static typing doesn't really help more than dynamic typing in these cases. Depends on the language and the business logic. Types are a way of specifying preconditions and postconditions; a more expressive type system lets you rule out more edge cases by making illegal states unrepresentable. In particular, I'm pretty sure it's not possible to have the thread bug from the article in Rust's type system.
- deleted 3y ago
  [deleted]
- makeitdouble 3y ago
  Speaking only for me, but one can get used to the limits of the system and adapt (put another, I'd tend to introduce as many logical bugs, but in different ways) For instance in a method that absolutely requires a specific type of object as a return, setting up a sacrificial default value to have the compiler happy, and actually build the inners of the function from there would be a normal course of action. That lets us run the code as we build it. But at the end if you forgot a case, it will still be a bug, except instead of having a wrong return type you get a wrong value. Weither it's better or not is up for debate.
- fijiaarone 3y ago
  It’s also not possible to write a non-trivial program in Rust.
  - throwaway2037 3y ago
    "Servo is a web rendering engine written in Rust" Is Servo non-trivial? I think yes.
  - cstrahan 3y ago
    > It’s also not possible to write a non-trivial program in Rust. You should probably clarify that it’s not possible for you to write non-trivial programs in Rust. And that’s okay! No one comes into this world knowing how to do any thing, but we can all learn if we choose to. If you have a particular sticking point, I’d be glad to give advice.
newZWhoDis 3y ago
Oh it absolutely matters. Rail apps in particular are full of “tests” a basic compiler would catch. So you save a “ton of time” writing the code without “cognitive overhead of types”, then you spend 3x as long writing the tests
lmm 3y ago
> Major bugs are not "oh this can be null" Not true. Even today the majority of security bugs are simple buffer overflows, for example. The subtle bugs are more memorable, but that doesn't mean they're actually more common. > major bugs are "this combination of preconditions yield a business logic edge case that wasn't accounted for". Static typing doesn't really help more than dynamic typing in these cases. It absolutely does, if you put a little bit of effort into actually using it. Represent your business logic invariants in the type system, then the compiler won't let you accidentally violate them.

throwaway290 3y ago

It matters enough that the question "does static typing dramatically reduce the benefits of unit testing" is an open question or at least seriously discussed in the industry. All other replies are about dynamic languages.

ska 3y ago
I don't think it is really unresolved. Static languages with sufficiently rich and modifiable type systems avoid a fraction of cases where you may well want a unit test, but it's not the overwhelming majority. Merely static helps too but not all that much. So while there is a reduction, it's a stretch to call it "dramatic".
- throwaway290 3y ago
  > I don't think it is really unresolved Well, you are currently participating in a thread that discusses this very question so there's that... and such threads are regular on HN. I meant just that. People discuss it. What you want to say is that you have a strong opinion about it, that's OK and still possible with open questions
  - ska 3y ago
    People discuss lots of things that are pretty well solved; i wouldn't equate "open question" with "lots of discussion". I guess in this context I mean that the question of static vs. dynamic in unit testing turns out to not be that hard, but the questions like "what is a unit test" and "should we unit test at all" are much muddier. Because people are confused or argumentative about the latter, they tend to pull the former into discussions that don't really have much to do with static vs. dynamic.
    - deleted 3y ago
      [deleted]
pfdietz 3y ago
Why isn't the question "does adequate testing dramatically reduce the benefits of static typing" asked? Why is static typing privileged by default?
- tshaddox 3y ago
  Probably because using a static type system gives you those benefits "for free," whereas unit tests are things you need to write and maintain. ("For free" in scare quotes because of course there are always tradeoffs between different programming languages.)
  - pfdietz 3y ago
    The counterargument is that for sufficiently reliable software extensive testing is needed anyway, and if you do that you find the type errors "for free". If the testing is insufficient, as in practice it often surely is, then static typing would seem to be more valuable.
- peterfirefly 3y ago
  It is asked. A lot.
- mayoff 3y ago
  I wouldn’t say static typing is privileged, but that testing is disadvantaged, because, in the words of Edsger Dijkstra, “Program testing can be used to show the presence of bugs, but never to show their absence!” https://www.cs.utexas.edu/users/EWD/transcriptions/EWD02xx/EWD249/EWD249.html https://www.cs.utexas.edu/users/EWD/transcriptions/EWD02xx/E...
  - funcDropShadow 3y ago
    We could paraphrase Dijkstra --- with some liberty -- to say, "Formal verification of programs can only show the specification is fulfilled, not that the specification is adequate."
- throwaway2037 3y ago
randomdata 3y ago
A fully evolved type system (e.g. Coq) overlaps with unit testing. But the vast majority of languages people actually use have only partial type systems that require unit tests to stand in where the type system is lacking. In practice, when you write those tests for where the type system is lacking, you end up also incidentally testing where there is type system coverage, so there likely isn't much for industry to talk about.
kibwen 3y ago
Having static types is like having an automatic, exhaustively comprehensive, efficient unit test generator for the classes of bugs whose units tests are the most boring and annoying to write and maintain. Static types don't prevent you from needing unit tests, they free you up to focus on writing tests that are actually interesting.
- deleted 3y ago
  [deleted]
- throwaway2037 3y ago
  I agree with your post. To be more specific, you can focus more on logic and state bugs.
- throwaway290 3y ago
  This, but depending on how good the type system is and how well it's used most remaining interesting tests may be integration aside from legit things like https://news.ycombinator.com/item?id=38692634 https://news.ycombinator.com/item?id=38692634
noselasd 3y ago
I'm writing unit tests in rust and c++, I'm in the same boat as the op, often finding logical errors while writing the tests. Not to mention peace of mind when you go and mess around with code you wrote 9 months ago - if you mess up or didn't think of a corner case, there's decent chance it'll get caught by existing tests.

_dain_ 3y ago

>"this combination of preconditions yield a business logic edge case that wasn't accounted for". Static typing doesn't really help more than dynamic typing in these cases. Depends on the language and the business logic. Types are a way of specifying preconditions and postconditions; a more expressive type system lets you rule out more edge cases by making illegal states unrepresentable. In particular, I'm pretty sure it's not possible to have the thread bug from the article in Rust's type system.

deleted 3y ago
[deleted]
makeitdouble 3y ago
Speaking only for me, but one can get used to the limits of the system and adapt (put another, I'd tend to introduce as many logical bugs, but in different ways) For instance in a method that absolutely requires a specific type of object as a return, setting up a sacrificial default value to have the compiler happy, and actually build the inners of the function from there would be a normal course of action. That lets us run the code as we build it. But at the end if you forgot a case, it will still be a bug, except instead of having a wrong return type you get a wrong value. Weither it's better or not is up for debate.
fijiaarone 3y ago
It’s also not possible to write a non-trivial program in Rust.
- throwaway2037 3y ago
  "Servo is a web rendering engine written in Rust" Is Servo non-trivial? I think yes.
- cstrahan 3y ago
  > It’s also not possible to write a non-trivial program in Rust. You should probably clarify that it’s not possible for you to write non-trivial programs in Rust. And that’s okay! No one comes into this world knowing how to do any thing, but we can all learn if we choose to. If you have a particular sticking point, I’d be glad to give advice.

newZWhoDis 3y ago

Oh it absolutely matters. Rail apps in particular are full of “tests” a basic compiler would catch. So you save a “ton of time” writing the code without “cognitive overhead of types”, then you spend 3x as long writing the tests

lmm 3y ago

> Major bugs are not "oh this can be null" Not true. Even today the majority of security bugs are simple buffer overflows, for example. The subtle bugs are more memorable, but that doesn't mean they're actually more common. > major bugs are "this combination of preconditions yield a business logic edge case that wasn't accounted for". Static typing doesn't really help more than dynamic typing in these cases. It absolutely does, if you put a little bit of effort into actually using it. Represent your business logic invariants in the type system, then the compiler won't let you accidentally violate them.