Even if it doesn’t help to find bugs, static typing is still worth it. I’ve been fixing some stuff in an existing Python codebase in the last weeks. Most of the time, when I see a new function, I have no idea what’s the type of its parameters...
Or maybe 'flex typing' as we have in TS.
I love that TS has 'any' type, because it really allows for some flex in development when you 'haven't figured the dam type out yet' - OR - you're dealing with untyped JSON-ish data.
A completed system has 'strong typing'. But a system is always in development. You're trying to do A, but in the meantime, B, C and D need types! And you didn't even know C and D needed to exist. Oops!
So you can tweak tsc to be a little lose with the facts and then as the module matures, tighten it up.
It's actually kind of interesting that TSC is one of the few 'compilers' (yea I know it's a transpiler) that actually gives you that amount of power over things.
This is great, because I can prototype fast even if thing's don't yet typecheck and when I have idea what I'm trying to a chieve I can document all code and polish rough cases without leaving the editor.
If everyone is a good engineer and comments things and tests things you’re going to have a great time. But if you start getting bad practices they’re going to be multiplied.
Not a disagreement, but an observation : verbatim the exact same thing has been said about Ruby, and - I imagine - every other widely used dynamically typed language on the planet.
IMO, maintainability is a well understood weakness of dynamic typing - hence every responsible Ruby/Python/JS/Perl codebase including a mountain of unit tests that do nothing but cover typing (in addition to the rest of the tests that would be present irrespective of implementation language)
At the end of the day there's no silver bullet : either we let the compiler handle type checking, or we cover it ourselves with unit tests. Doing neither isn't really much of an option, but it is probably where a lot of these type-related bugs come from.
For that reason I usually use types for defining utility functions that get re-used in multiple places throughout the app. For everything else I just name the variables according to what the thing is, e.g.:
user_model, user_model_list, user_id_set, user_id_to_user_model_dict, etc. If you have a good style guide, there really should only be one allowable name for any given variable, and it should be immediately clear what type each variable is from the suffix on the name.
What's the point of naming based on types, instead of just declaring types so they can be programmatically analyzed by your tools?
More readable. When declaring a type you only see the type when the variable is declared or when it's passed into a function, whereas when putting the type in the name it's obvious in each line where it's used so you don't need to waste working memory on remembering what things are.