Whether it's worth the effort is debatable. When you (not you specifically, in general) design a database, do you use types, do you mark a field as int or let everything be a string? Yes, when you code you can make sure to only put "integers" (as string) in that field and everything will work. Maybe it's not the perfect analogy, but I think it touches an important point. From a statically-typed point of view it "feels" dirty. When I look at a method declaration, I want to know that it only works with integers, the same way I look at a field in the database I want to be sure to expect only integers, and nothing else.
> When I look at a method declaration, I want to know that it only works with integers, the same way I look at a field in the database I want to be sure to expect only integers, and nothing else.
That's fine, but it doesn't help me with the errors that I make.
I don't make representation errors. I make kind errors. The difference is that the number of apples and the number of bananas are both non-negative integers, but a check for non-negative integers doesn't keep me from adding apples to my bananas inventory. Remember that I do want to add both apples and bananas to my fruit inventory.
Yes, I care about representation, but things shouldn't go south if I happen to have half an apple.
In some statically typed languages, it is possible to have an "Apples" and a "Bananas" type. And it's good to hear that you don't make "representation errors", because I do make these errors - which then blow up precisely after 3 hours of running the Python program.
But noting types is not the same as the specifics of a type system. Merely marking what types a function accepts can be accomplished just as easily with a comment like "# function foo : (int, int) -> int".
But anyway, in many cases, structural typing can make more sense than name-based typing.
Indeed, that is the definition of a static type system. And that's a useful thing to have. But it's not infinitely useful. In some cases, the burden of pleasing the type system can be bigger than the burden of checking types yourself where necessary. Static typing can actually get in the way of useful algorithms if (for example) your type system doesn't support generics.
Due to these tradeoffs, in some cases, people can be more productive in a language without the help of a typechecker than they can in certain languages' static type systems.
