I don't think most people who program in dynamically typed languages believe that. However there are people in the extreme that believe that static typing will save you from errors. Sometimes I worry that the cognitive overhead of and code legibility, conciseness, and lax documentation that become habits in static typed languages add complexity to the program which is antithetical to maintainability. In practice, static typechecking of a dynamic language is probably enough. Especially erlang family languages do a great job of keeping type annotations looking "more like documentation" which is how it ought to be.
Many real-world entities don't have a fixed set of characteristics/properties; instead, they have fluid characteristics that can change over time.
Trying to model those entities using static types which have a fixed/static set of properties is a bad idea.
For example, in nature, a tadpole might grow arms and legs and become a frog. Trying to represent a single entity using two different classes 'Tadpole' and 'Frog' doesn't always work... What type is the creature if it's exactly halfway between being a Tadpole and a Frog? Do you keep inventing new discrete types to keep re-categorizing the creature as it grows or do you acknowledge that the exact type of this creature cannot be expressed discretely but that it lies on a continuum?
It's an animal. The type checker will make sure you don't try to water() it. Static typing does not have to mean infinitely granular typing (though of course typing everything "statically" as any is pointless).
Unless s/errors/all errors/ that isn't extreme at all.
I think that's a misleading summary. Both dynamic and static languages suffer when it comes to changes over time (people will argue over which suffers more, but both suffer) so solving problems you haven't thought through is hardly a problem unique to dynamic languages.
My primary benefit is not spending the time telling the computer things it should already know. Dev time is the most limited resource, I prefer not to spend it restating the obvious. And yes, sometimes this restatement could be complex to express.
The biggest benefit I see most static typing advocates benefiting from is IDE-hints, not compile-time checking. But IDE hints aren't what people use to advocate for static typing.
There are many reasons for different approaches - but if you want to limit it to a single thing, feel free. Just don't expect many people to be convinced, or even interested in your arguments.
Sounds like you're in favour of type inference, not dynamic typing. A lot of statically typed languages don't need you to type out type declarations of your functions.
> Dev time is the most limited resource, I prefer not to spend it restating the obvious.
But on a typical dev job, you spend 10 times more reading code than writing it. And when you read, these type declarations actually save your time.
> The biggest benefit I see most static typing advocates benefiting from is IDE-hints, not compile-time checking.
Uhm, no? I'm pretty sure it's about the guarantees that compiled languages give you - the more invariants, the better. The same logic as with immutability.
Cells (co-)evolved for billions of years, they were not "designed" to accomplish certain tasks. Just survival and reproduction. And still, even with those billion of years, we still have cancer (as in bug in the reproduction process).
We design software. We evolve software. Software doesn't build itself, or decide for itself what's the best way to accomplish some task. We maintain software, we need guarantees, as much as we can get.
Dynamic languages let you think a problem you haven't thought of at design time will somehow solve itself magically at runtime, using components designed weeks before, with knowledge of that time.
It just doesn't work. It's an ideal vision that explodes as soon as your software gets any kind of commercial success and longevity, and you need to maintain it, and evolve it.