3 ms·

> When working in modular units or decoupled teams, when one team gets some code they know that if type checking has passed a set of requirements have been met.

> When working in modular units or decoupled teams, when one team gets some code they know that if type checking has passed a set of requirements have been met. They understand what that means. While unit tests are useful, you passing your unit tests means very little to me, until I spend a few days going through your unit tests. Except that "type checking has been passed" doesn't actually tell you anything about correctness either without spending a few days going through the types. It's very easy, and very common, for bad programmers to build a few BigBallOfStuff types and essentially re-invent an ad-hoc dynamic type system that will pass static analysis in a way that is utterly meaningless when it comes to behavioural correctness

kenjackson 16y ago
There is a very big difference. It's that when I write code I need to use your types. If I'm getting a BigBallOfStuff I instantly know that your type checking is constrained based on the types. With virtually any external testing (unit, integration, UI, or most other) working with the product code is not sufficient to determine the quality of the testing. The tests must be looked at specifically. Type checking and other forms of static analysis run on the code themself, which means that I only need to inspect the product code -- which I pretty much have to do to write any code with it.
silentbicycle 16y ago
A BigBallOfStuff type should stick out like a sore thumb in a code review, though. Static typing is a DSL for specifying assumptions in a way the compiler can check. If you misuse it, it can backfire, but that's true of pretty much everything.
- msbarnett 16y ago
  That's just a recasting of "if you rigorously specify all of your assumptions in your unit tests, you needn't worry about anything". You can take maximal advantage of the type system to encode assumptions, but it's still on you to do it. This isn't a silver bullet that makes static typing better than dynamic typing, because nothing forces you to be competent about specifying your assumptions here, either. You can take maximal advantage of the type system to specify as many assumptions as it can check or you can take maximal advantage of the unit tests to specify the same assumptions. You end up in the same place either way, and the OP's claim that you can "trust" the existence of passing type-checks without looking at the types to see what assumptions they encode in a way that you cannot trust unit tests doesn't hold up.
  - silentbicycle 16y ago
    Agreed. I think some mix of declarations and automated (regression, etc.) testing is probably most practical. I like randomized testing, as well.

kenjackson 16y ago

There is a very big difference. It's that when I write code I need to use your types. If I'm getting a BigBallOfStuff I instantly know that your type checking is constrained based on the types. With virtually any external testing (unit, integration, UI, or most other) working with the product code is not sufficient to determine the quality of the testing. The tests must be looked at specifically. Type checking and other forms of static analysis run on the code themself, which means that I only need to inspect the product code -- which I pretty much have to do to write any code with it.

silentbicycle 16y ago

A BigBallOfStuff type should stick out like a sore thumb in a code review, though. Static typing is a DSL for specifying assumptions in a way the compiler can check. If you misuse it, it can backfire, but that's true of pretty much everything.

msbarnett 16y ago
That's just a recasting of "if you rigorously specify all of your assumptions in your unit tests, you needn't worry about anything". You can take maximal advantage of the type system to encode assumptions, but it's still on you to do it. This isn't a silver bullet that makes static typing better than dynamic typing, because nothing forces you to be competent about specifying your assumptions here, either. You can take maximal advantage of the type system to specify as many assumptions as it can check or you can take maximal advantage of the unit tests to specify the same assumptions. You end up in the same place either way, and the OP's claim that you can "trust" the existence of passing type-checks without looking at the types to see what assumptions they encode in a way that you cannot trust unit tests doesn't hold up.
- silentbicycle 16y ago
  Agreed. I think some mix of declarations and automated (regression, etc.) testing is probably most practical. I like randomized testing, as well.