4 ms·

> what you can already prove. bazoom42 touches on the value testing aspect that goes beyond the mere type or return. Typing and compilers also only guarantee

> what you can already prove. bazoom42 touches on the value testing aspect that goes beyond the mere type or return. Typing and compilers also only guarantee coherency inside your declarations. If for instance you're expecting some library to return an int, but it's utterly broken and actually tries to return a string, the strong typing system will only let you identify why it's crashing in production. Hopefully you'd want to detect this class of issues beforehand.

HideousKojima 2y ago
>Typing and compilers also only guarantee coherency inside your declarations. If for instance you're expecting some library to return an int, but it's utterly broken and actually tries to return a string, the strong typing system will only let you identify why it's crashing in production. Hopefully you'd want to detect this class of issues beforehand. If I try to call a third party library method in a language with a sane type system (like C# or Rust) that returns a string and attempt to assign that value to an int, it won't even compile. And I'll get a red squiggly line before I even try to compile. What you're saying would only apply in something like Python or TypeScript where you might be using types/type annotations but the library you're calling isn't.
- makeitdouble 2y ago
  > If I try to call a third party library method in a language with a sane type system (like C# or Rust) that returns a string and attempt to assign that value to an int, it won't even compile. You're assuming that for instance the library is correctly setup and won't crapout because a system requirement is not met. Or that no other external factor will interfere with the result (e.g. your library is hooked to an API) Compile time checks will be against a declared interfaces, not the actual library built outside your project. To me that's the kind of issues where having a test coverage really helps, a lot more than just checking that mocks and interfaces match each other (to show my hand, I prefer dynamic languages, so interfaces will rarely fail and many edge cases can be simply be coerced into a generic path, so the real scary stuff is when the rubber meets the road and expectations meet reality)
  - HideousKojima 2y ago
    >You're assuming that for instance the library is correctly setup and won't crapout because a system requirement is not met. Or that no other external factor will interfere with the result (e.g. your library is hooked to an API) Correct, and if that isn't the case then that's a problem with the library, not my code. In C# I've had none of the issues you just mentioned with libraries, with the exception of ones that expect some specific native DLL to be present that the C# library calls into. And unit testing won't save you from that issue because the system you're running your tests on isn't the same as the system prod is running on. To be frankly honest I question how much you know/understand about languages with strong type systems based on your comments.

HideousKojima 2y ago

>Typing and compilers also only guarantee coherency inside your declarations. If for instance you're expecting some library to return an int, but it's utterly broken and actually tries to return a string, the strong typing system will only let you identify why it's crashing in production. Hopefully you'd want to detect this class of issues beforehand. If I try to call a third party library method in a language with a sane type system (like C# or Rust) that returns a string and attempt to assign that value to an int, it won't even compile. And I'll get a red squiggly line before I even try to compile. What you're saying would only apply in something like Python or TypeScript where you might be using types/type annotations but the library you're calling isn't.

makeitdouble 2y ago
> If I try to call a third party library method in a language with a sane type system (like C# or Rust) that returns a string and attempt to assign that value to an int, it won't even compile. You're assuming that for instance the library is correctly setup and won't crapout because a system requirement is not met. Or that no other external factor will interfere with the result (e.g. your library is hooked to an API) Compile time checks will be against a declared interfaces, not the actual library built outside your project. To me that's the kind of issues where having a test coverage really helps, a lot more than just checking that mocks and interfaces match each other (to show my hand, I prefer dynamic languages, so interfaces will rarely fail and many edge cases can be simply be coerced into a generic path, so the real scary stuff is when the rubber meets the road and expectations meet reality)
- HideousKojima 2y ago
  >You're assuming that for instance the library is correctly setup and won't crapout because a system requirement is not met. Or that no other external factor will interfere with the result (e.g. your library is hooked to an API) Correct, and if that isn't the case then that's a problem with the library, not my code. In C# I've had none of the issues you just mentioned with libraries, with the exception of ones that expect some specific native DLL to be present that the C# library calls into. And unit testing won't save you from that issue because the system you're running your tests on isn't the same as the system prod is running on. To be frankly honest I question how much you know/understand about languages with strong type systems based on your comments.