Tests tend to test values. Types generally don't catch wrong values, so if you implement add() as subtract(), the signatures are the same, but you still get a wrong result.
However, tests of values incidentally also test the types, because values have types and for the values to match, the types must also match.
So if you write the tests that you need to write anyhow, the ones for the values, you have also tested the types, without extra effort.
Tests check the values, but that doesn't mean it's the only thing they test. When you say 'incidentally' you are conflating the goal with the means.
Anyway, my point is that dynamic typing creates a whole category of errors and make much easier to make several other kinds of mistakes and, what is worse, delay the moment in which they're obvious.
> but that doesn't mean it's the only thing they test.
That was exactly my point. In checking values, they also check types, without any extra effort.
> creates a whole category of errors
It doesn't create them. It just doesn't prevent them (type errors) at the language/compiler level. But since you have to test the values anyway, that doesn't really matter.
> delay the moment
Not really. Dynamic languages make possible environments that compile+run before the static compiler is done compiling.
That line of reasoning is the same as certain persons that "sell protection": they want you to pay to solve a problem that was much smaller before they appeared. Of course they try to convince you that the problem was already there.
Not really. Dynamic languages make possible environments that compile+run before the static compiler is done compiling.
You're confusing dynamic types with dynamic compilers. Or maybe you mean speed? There are very fast compilers, I assume your reference is C++ that is a dog. Anyway that's a red herring, because the delay I was talking about is logical, not about the implementation.
Hmm...static type checking is something you add to a programming language, so you seem to have your causalities mixed up a bit.
> confusing dynamic types with dynamic compilers
Nope. Most of the compilers for languages for different kinds of rich static type systems are slow, and getting slower. Yes, C++, but also Haskell, Scala and Swift. Some have Turing-complete type-systems, so you actually have no guarantee that compilation will even terminate, never mind the time it will take.
An almost bigger point is incrementality. A language/system like Smalltalk lets you compile a method at a time without stopping the running program, and you can do an exploratory step that is allowed to be inconsistent without having to fix all related code.
The development experience is something that has to be seen and lived to be believed.
> Most of the compilers for languages for different kinds of rich static type systems are slow, and getting slower
It's not the types that make Haskell slow to compile, as you can verify but running a type-check only pass using -fno-code. You will find it run an order of magnitude quicker than a full compile.
Tests tend to test values. Types generally don't catch wrong values, so if you implement add() as subtract(), the signatures are the same, but you still get a wrong result.
However, tests of values incidentally also test the types, because values have types and for the values to match, the types must also match.
So if you write the tests that you need to write anyhow, the ones for the values, you have also tested the types, without extra effort.