I think gradual typing is definitely likely to become the norm. It allows you to develop things using the dynamic style and then add type annotations where appropriate. It also avoids the problem of mixing the proof into your solution.

I think the main problem with types isn't that they slow you down. In my experience they actually don't and reverse is actually the true. The main problem is that static languages are often too complicated for non professional software developers, i.e. designers, system administrators, data scientists, etc, to be motivated to learn them. They just need to write the code, and when they do it themselves, the stuff is done much faster and much more efficiently.

The inherent complexity of static typing is precisely my argument. You have to demonstrate that the additional complexity actually adds value in the long run. This seems like a prerequisite before you start extolling this approach.

Types and the type system are actually orthogonal to the code. They constrain the allowable semantics but nothing requires them to be commingled.

I would say Java (the native syntax) is over engineered. The runtime is a beautiful thing.

>I would say Java (the native syntax) is over engineered. The runtime is a beautiful thing.

It's not over-engineered. Making syntax in this way was a design goal. AFAIU, authors of the language thought that when you specify as much as possible in syntax, the code is easier to maintain. That's why it's so popular in enterprise world where code often lives for 10s of years.

> when you specify as much as possible in syntax, the code is easier to maintain

That's not true of all cases. Most importantly, the number of abstractions that are baked into the language are a combination of workarounds (rather than fixing the type system) and whatever the JLS contributor's motivations are. Some of which has been useful, some of which has not. It's overengineered.

I don't know if it's overengineered, so much as it's poorly engineered.