"static typing is still worth it. "

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.

I use TS with transpileOnly flag (compile even if type errors).

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.

C# has "dynamic", which is similar in spirit.

I like to think of python as a language that’s great for responsible adults.

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.

Heh. I’d counterargue by asking how many times you’ve heard of someone joining a new job and looking at the code and saying, “Ah, this is clearly written by responsible adults!”

Don't be cynical; I've definitely looked for work in companies that have good codebases.

> I like to think of python as a language that’s great for responsible adults.

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.

You also have to unfailingly keep comments up to date. Our org struggles a lot with this, but I wouldn’t say we are irresponsible apart from the fact that we’re using a language that makes humans do error-prone tasks that are already solved by automation. :)

> Most of the time, when I see a new function, I have no idea what’s the type of its parameters...

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.

Isn't that just ad-hoc typing?

What's the point of naming based on types, instead of just declaring types so they can be programmatically analyzed by your tools?

> What's the point of naming based on types

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.

Ah yes, the old Hungarian notation (or variation on that idea). Makes sense in some contexts.

If you’re using a new enough version of Python 3 then you can add type annotations now. Not great by any means but it’s made working with a large-ish python codebase tolerable (together with PyCharm).

I usually write code in the ipython console and copy it back once it's in a fit state. Type lookup in that environment is trivial.

And so how can you even be sure it does what you think. The types are only part of the equation.

I have very strong opinions on docstrings; they are simple to implement and completely solve this issue.

I wouldn’t say “completely”, because they’re not guaranteed to be accurate, even when first created, much less down the road.

Listing arguments and their types in docstrings always feels likea bad idea for this reason.

That's what Hungarian notation is for.