5 ms·

> Squashing any error, strangeness and warning can be very expensive in some projects Strongly disagreed. Strange, unexpected behaviour of code is a warning s

> Squashing any error, strangeness and warning can be very expensive in some projects Strongly disagreed. Strange, unexpected behaviour of code is a warning sign that you have fallen short in defensive programming and you no longer have a mental model of your code that corresponds with reality. That is a very dangerous to be in. Very quickly possible to be stuck in quicksand not too far afterwards.

huijzer 2y ago
Depends a lot on the project, I think, as the parent comment suggests.
saagarjha 2y ago
I mean, it is expensive. It’s just that the alternative might be more so.
- fmbb 2y ago
  > might be Yes. Or it might be cheaper.
fc417fc802 2y ago
I feel like these categories are different. Warnings should generally be treated as errors in my book, and all errors should be corrected. But "strangeness" is much more open ended. Sometimes large systems don't behave quite as expected and it might make sense to delay a "fix" until something is actually in need of it. If none of your tests fail then does it really matter?
- alex_smart 2y ago
  > If none of your tests fail then does it really matter? Yes. Absolutely. You don't believe your software is correct because your tests don't fail. You believe your software is correct because you have a mental model of your code. If your tests are not failing but your software is not behaving correctly, that your mental model of your code is broken.
  - taneq 2y ago
    And/or so are your tests.
    - alex_smart 2y ago
      No, they are not. They are a cheap way of verifying that something hasn't gone wrong, not a proof of correctness. Tests failing implies the code is incorrect. Tests not failing does not imply that the code is correct.
      - fc417fc802 2y ago
        > Tests not failing does not imply that the code is correct. I don't think that's what's being suggested. Tests not failing when your code does implies that you are missing test cases. In other words things are underspecified. Haskell is the extreme example of this. If it successfully compiles then it most likely does exactly what you intended but it might be difficult to get it to compile in the first place.
        alex_smart 2y ago
        >Tests not failing when your code does implies that you are missing test cases. In other words things are underspecified. I am really confused. Have you guys never written any multithreaded code? You can write the most disgusting thread-unsafe code without a single lock and be perfectly green on all your tests. And who in the world can write tests to simulate all possible timing scenarios to test for race conditions? I give multithreading as just the most egregiously obvious example that this "tests can prove correctness" idea is fundamentally broken, but I think it applies more generally. >Haskell is the extreme example of this. If it successfully compiles then it most likely does exactly what you intended but it might be difficult to get it to compile in the first place. Absolutely 100% of the safety of haskell comes from the mental model (functional programming, immutable data structures etc) and none from the test cases (although their community appears to even do testing slightly better than others).
taneq 2y ago
100% this. If our product does something unexpected, finding out why is top priority. It might be that everything’s fine and this is just a rare edge case where this is the correct behaviour. It might be a silly display bug. Or it might be the first clue about a serious underlying issue.

huijzer 2y ago

Depends a lot on the project, I think, as the parent comment suggests.

saagarjha 2y ago

I mean, it is expensive. It’s just that the alternative might be more so.

fmbb 2y ago
> might be Yes. Or it might be cheaper.

fc417fc802 2y ago

I feel like these categories are different. Warnings should generally be treated as errors in my book, and all errors should be corrected. But "strangeness" is much more open ended. Sometimes large systems don't behave quite as expected and it might make sense to delay a "fix" until something is actually in need of it. If none of your tests fail then does it really matter?

alex_smart 2y ago
> If none of your tests fail then does it really matter? Yes. Absolutely. You don't believe your software is correct because your tests don't fail. You believe your software is correct because you have a mental model of your code. If your tests are not failing but your software is not behaving correctly, that your mental model of your code is broken.
- taneq 2y ago
  And/or so are your tests.
  - alex_smart 2y ago
    No, they are not. They are a cheap way of verifying that something hasn't gone wrong, not a proof of correctness. Tests failing implies the code is incorrect. Tests not failing does not imply that the code is correct.
    - fc417fc802 2y ago
      > Tests not failing does not imply that the code is correct. I don't think that's what's being suggested. Tests not failing when your code does implies that you are missing test cases. In other words things are underspecified. Haskell is the extreme example of this. If it successfully compiles then it most likely does exactly what you intended but it might be difficult to get it to compile in the first place.
      - alex_smart 2y ago
        >Tests not failing when your code does implies that you are missing test cases. In other words things are underspecified. I am really confused. Have you guys never written any multithreaded code? You can write the most disgusting thread-unsafe code without a single lock and be perfectly green on all your tests. And who in the world can write tests to simulate all possible timing scenarios to test for race conditions? I give multithreading as just the most egregiously obvious example that this "tests can prove correctness" idea is fundamentally broken, but I think it applies more generally. >Haskell is the extreme example of this. If it successfully compiles then it most likely does exactly what you intended but it might be difficult to get it to compile in the first place. Absolutely 100% of the safety of haskell comes from the mental model (functional programming, immutable data structures etc) and none from the test cases (although their community appears to even do testing slightly better than others).

taneq 2y ago

100% this. If our product does something unexpected, finding out why is top priority. It might be that everything’s fine and this is just a rare edge case where this is the correct behaviour. It might be a silly display bug. Or it might be the first clue about a serious underlying issue.