> Not really, in my opinion. Type inference especially has come a long way.
Does dynamic typing also make writing tests easier?
For example when writing tests in Python it's relatively trivial to mock out specific methods or functions. However, when I was writing tests in Go, I realized to test things which required mocks I would have to change all the type signatures to use interfaces instead of structs, and that required writing a new interface as well.
I admit I am not entirely sure whether this difficulty stems from static vs dynamic typing or something else.
Honestly this is why I think dynamic languages with optional type systems tacked on are the best.
You get a huge amount of power in your type system (Python is actively working on dependent types and supports variance first class), but for code where that's a burden (test cases), you can drop it.
Maybe powerful macros that let you copy an interface (Python's mock.patch with autospec=true, but better) would solve the same problems, but you don't generally have that option.
Go is not very impressive when it comes to type system power though. My bet is that if you wrote your statically typed code in Crystal instead, then you wouldn't have any problems creating your mocks. There is nothing in the concept of static typing that forbids duck typing - it is just that most type systems are weak enough that it doesn't work.
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.
Does dynamic typing also make writing tests easier?
For example when writing tests in Python it's relatively trivial to mock out specific methods or functions. However, when I was writing tests in Go, I realized to test things which required mocks I would have to change all the type signatures to use interfaces instead of structs, and that required writing a new interface as well.
I admit I am not entirely sure whether this difficulty stems from static vs dynamic typing or something else.