On the other hand, you also lose some simplicity if you use a language where the contents of a given variable could take on literally hundreds of different forms — some of which you weren't even aware of when you wrote the code — and could change form unpredictably at any time. There is a lot of complexity inherent in dynamism.
The trick is, most of the time it doesn't matter. So long as it quacks like a duck, and we need the value to quack like a duck, we don't really care that it's a wolf with a duck call.
But most of the types in your program probably do not quack like ducks. Even the ones that seem duck-like enough that somebody might deliberately pass them into your function sometimes turn out to actually honk like a goose (e.g. bytes vs. str in Python, or unicode vs. str in other versions of Python).
Having used mostly dynamic languages throughout my career, personally, a huge number of the errors I've encountered have boiled down to getting the wrong type of thing — an unexpected null, a Business where I expected a Person, an array where I expected a string, an escaped HTML string where I expected an unescaped one, etc. Sometimes they quack kind of like a duck, but still do it differently enough to trigger faulty behavior (e.g. people and businesses both have names and addresses, but the latter can be in multiple places at the same time).
It usually works right, but in the cases where you're passing sensible types, you'll probably be OK in a statically typed language too — not always, but usually. Static type systems introduce some edge cases where you need to think about the type system even though you shouldn't have to, and dynamic type systems introduce other edge cases where your program's behavior can be unexpectedly brittle. They're both kinds of unnecessary complexity.
Comments
On the other hand, you also lose some simplicity if you use a language where the contents of a given variable could take on literally hundreds of different forms — some of which you weren't even aware of when you wrote the code — and could change form unpredictably at any time. There is a lot of complexity inherent in dynamism.
The trick is, most of the time it doesn't matter. So long as it quacks like a duck, and we need the value to quack like a duck, we don't really care that it's a wolf with a duck call.
But most of the types in your program probably do not quack like ducks. Even the ones that seem duck-like enough that somebody might deliberately pass them into your function sometimes turn out to actually honk like a goose (e.g. bytes vs. str in Python, or unicode vs. str in other versions of Python).
Having used mostly dynamic languages throughout my career, personally, a huge number of the errors I've encountered have boiled down to getting the wrong type of thing — an unexpected null, a Business where I expected a Person, an array where I expected a string, an escaped HTML string where I expected an unescaped one, etc. Sometimes they quack kind of like a duck, but still do it differently enough to trigger faulty behavior (e.g. people and businesses both have names and addresses, but the latter can be in multiple places at the same time).
It usually works right, but in the cases where you're passing sensible types, you'll probably be OK in a statically typed language too — not always, but usually. Static type systems introduce some edge cases where you need to think about the type system even though you shouldn't have to, and dynamic type systems introduce other edge cases where your program's behavior can be unexpectedly brittle. They're both kinds of unnecessary complexity.