> This is a straw man argument.
That would imply ill intent on my part, and there was nothing of the sort. All I said was that I couldn't see the sense in certain things and, without further explanation, I didn't. Other comments helpfully pointed out the context for why the assertion is so often made and I was happy with it.
On the other hand, I think I'd need to see some hard evidence for the following assertions:
> When the types are complicated enough, people no longer read them
What is a complicated type?
> As the person writing the code, figuring out what the types actually are and writing them down doesn't actually help anyone.
Citation needed. I find static typing tremendously helpful in my own code, especially if it's code I haven't worked on in a long while.
> It's just busy work that the compiler or interpreter could have inferred
… such that I only notice errors when the code is running, not beforehand. Without type annotations, interpreted languages like Python and Ruby are happy to let wrong types in function calls and message passes slide — which is why frameworks like Sorbet exist, to help eliminate that class of error.
> 2.
All of that is language-specific, surely, not really anything to do with static or dynamic typing. That whole mechanism is quite straight-forward and has a well-prescribed mechanism in Swift, for instance, with protocols, extensions, and conditional conformance.
> OTOH, in a dynamic language, all of that work is just gone.
I mean, it's not just gone. There are trade-offs, of course there are; but the assertion that the work is gone also implies the potential associated errors are gone seems a bit ingenuous to my eyes.
Yeah, types can be a bit constraining — but at the same time, if you reason about them properly and according to the language's prescribed mechanism rather than fight them, it can and does become second nature. At that point, using types becomes as simple for some as not using types is for others.