Exhausting, yes, why would we need to prep our own meal if it can be served to order?

Types are needed for sure, but don't make up for the fact we have to prep our own meals from time to time, even the best recipes don't cover all variations.

For me the variation is one of the places where dynamic typing gets really dangerous, because as variations increase, the requirement for code archaeology does as well. At some point there is enough variation that nobody could reasonably be expected to do enough code exploration to understand the full breadth of that variation.

With types, the scope of the variation is clearly stated, and if you want to expand the variation, it should be clear how to do so, depending on the flavor (e.g. union types, sum types, generics, sub types).

It's definitely easier to extend existing recipes than having to start from none. What I tried to get at, is that even with in-depth recipes, there's a bigger codebase picture behind the type, that GP found exhausting navigating without.

I think if we start to lean on types for our all recipes, we may forget how to prepare them without instruction.

In general though, a strong statically typed language will allow the user to locally reason to a much greater extent.

If there’s a lot of variations that’s exactly when you need help from typing to not mess things up.

If the modelling is trivial, the ROI is much lower (although the devx benefits still make it worth it to me)

static types: write types into the code to make the compiler happy, when trying to think about more important stuff

dynamic types: method parameter name gives the type and comment gives the method return type — conventions show what data is supposed to be

static types are disruptive and exhausting :-)