[wait_a_minute]

> We have projects in java7 still which span thousands of LoC and juniors can just jump in using their IDE and make some sort of contribution.

This seems to be a main reason certain people like it. It gives a sense of productivity. However I think it is misguided. It’s a false sense of productivity. Can they commit? Maybe, yes. Will it be right? Maybe, and more likely with types to handhold. But does it mean they understand the data model and the domain of the codebase they’re working in? No. No typing forces you to know what your code is actually doing.

It takes longer to be productive, but you’ll be productive because you know what you’re doing. Not because the IDE held your hand.

Widget factories or scrum farms will no doubt like the “ease” of jumping into a codebase that has typing, but I’m not yet convinced it’s better or that much better for the experience developer. I need to think on it more. For certain though I’ve seen enough in my time to know that how quickly a junior can “just jump in and make some sort of contribution” is not a good measurement.

[master-lincoln]

Your argument sounds like a language should make it hard to understand parts of a codebase without understanding the underlying parts as well. I would argue this goes against the goal of abstracting problems to keep complexity manageable.

Of course abstractions can be misunderstood and misused, but is that an argument for not having them?

[berkes]

"Truly understanding what goes on" and "static typing" are in no way correlated, let alone causations.

You are making a false dichotomy.

It's perfectly possible to work in a dynamic codebase without understanding the domain, business, logic or big picture. And it's just as perfectly possible to build a statically typed codebase that forces you to understand the whole entirety before being able to make a change.

Now, whether it's actuallygood to enforce true understanding of the Whole, before being able to work on a subset, is another debate. One that, unsurprisingly, has long been proven to be false. It's why we consider modules, functions, boundaries, coupling, classes, microservices, layers, and so fort and so on.

[marcosdumay]

Nope. A new dev will need a lot longer to understand a large python codebase than a java one.

In fact, if all the developers change, it's a virtual certainty that none will ever understand the python code, while the odds are about even for java.

(But then, the types aren't the only factor for that.)

[BigJono]

Dude, duck for cover, lol.

You're 100% right though.