This article feels a bit condescending. Like most things, it's a trade-off. While sophisticated types do have a lot of advantages over dynamically typed languages (I spend most of my time using languages like that), that doesn't mean there's no trade-off.
Dynamically typed languages are, in my opinion:
* Simple
* Typically require less design upfront
* Easier to get started with
There's real value in that. Perhaps not for the author. It's easy to scoff at languages like ruby, python or javascript and claim they're completely inferior to 'real languages', but there are completely valid reasons to use them. The real value comes from simplicity.
If you use a language where runtime/dynamic typing is a subset of what's possible, you lose that simplicity.
Exactly, another use is prototyping value. A language in which you can hammer a prototype out without thinking about or solidifying all the exact details -- it's more about trying out the concept, after all -- is infinitely easier to prototype with. After testing if the concept works, move to a more rigourous type system so you can bulletproof it against possible errors, etc.
While I completely agree, the sheer amount of "proto-duction" projects that are floating around and that I've had to try and maintain over the years makes an interesting argument for statically typed languages, I think!
I disagree with this (possibly depending on your particular value of "require"). The assistance that static typing can give in refactoring means I don't have to be nearly as confident in my initial design. Without the types, it's a lot more important that I get everything right initially. I find this to be true even when prototyping.
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
This article feels a bit condescending. Like most things, it's a trade-off. While sophisticated types do have a lot of advantages over dynamically typed languages (I spend most of my time using languages like that), that doesn't mean there's no trade-off.
Dynamically typed languages are, in my opinion:
* Simple
* Typically require less design upfront
* Easier to get started with
There's real value in that. Perhaps not for the author. It's easy to scoff at languages like ruby, python or javascript and claim they're completely inferior to 'real languages', but there are completely valid reasons to use them. The real value comes from simplicity.
If you use a language where runtime/dynamic typing is a subset of what's possible, you lose that simplicity.
Exactly, another use is prototyping value. A language in which you can hammer a prototype out without thinking about or solidifying all the exact details -- it's more about trying out the concept, after all -- is infinitely easier to prototype with. After testing if the concept works, move to a more rigourous type system so you can bulletproof it against possible errors, etc.
While I completely agree, the sheer amount of "proto-duction" projects that are floating around and that I've had to try and maintain over the years makes an interesting argument for statically typed languages, I think!
"Typically require less design upfront"
I disagree with this (possibly depending on your particular value of "require"). The assistance that static typing can give in refactoring means I don't have to be nearly as confident in my initial design. Without the types, it's a lot more important that I get everything right initially. I find this to be true even when prototyping.
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.