I think you are making a good case for a somewhat different point: we have long reached the point where the tools we use for writing and reading programs can give us all sorts of semantic information on demand, and language syntax design should take advantage of the fact that everything the programmer needs to know need not be forced into just one flat page-of-text view of the code.

Alan Kay made essentially this suggestion when the requirements for the language that became Ada were being debated, but it was not taken up at that time.

But that doesn't mean hide everything from view just because it can be accessed via a keyboard short-cut or mouse movement - my eyes are faster and easier to move. Also, code isn't read exclusively in an IDE, nor the same IDE that I use.

A lot of tools can put the type inference result for all variables when you are reading code (pycharm does it during runtime but IntelliJ + rust did it dynamically as I typed if I recall correctly)

This has always been the case. Emacs could do all this decades ago. Genera/Lisp, Smalltalk, etc. to various degrees did this. And they all failed to make their case. Time after time. Hiding context has always been bad for understanding code. The same reason dynamic scoping went out of style the moment lexical scoping was invented. Or that GOTO is considered harmful. Or that we all prefer simple, small functions rather than multi-page monsters that do ten different things at once.

Showing all the context has never been feasible, and abstraction is about how to deal effectively with that constraint. Types are abstractions, and consequently explicitly declaring a variable's type does not provide all the context.

The original C++ 'throw' declaration is an example of an ill-conceived attempt to provide and use more context, and an example where tools provide a better solution than piling on the syntax.

Sure, type inference isn't always better, but it's usually clearer — I almost always already know the type of the thing, so explicit types are just noise — and languages with inference still let you write

    let me: Person = something.getOwner();

so you still have the freedom to write the type explicitly.

All the major Rust IDEs (VS Code, IntelliJ, and probably Vim + others) show the variable type inline when you don't provide it explicitly: https://i.imgur.com/96Wfukl.png

The white text on a gray background is provided by my IDE.

My personal experience with C# and Typescript has been that explicit typing like that rarely provides much value. Explicit typing tells me one thing and one thing only: GetOwner() returns a Person. But when I have questions, they almost always fall into the realm of "details about the GetOwner() method" or "details about the Person type". I honestly am struggling to think of any examples when seeing a variables type answered all of my questions.

Honestly though, this is a tooling problem. There's no reason at all that developers should need to spend time encoding information into the source code that's already known to the compiler, but devs also need to use tools that can feed the compiler's knowledge back to them. Jetbrains Rider (and their Resharper extension for Visual Studio) have a set of options called inlay hints [1] that do this exact thing. Personally I tend to keep most of the type hints turned off because they do add a lot of clutter, but the feature is absolutely invaluable for parameter name hints.

[1]: https://www.jetbrains.com/help/rider/Inline_Parameter_Name_H...

In the case of Java you have the option of using "Person me" or "let me". Simply stick to the convention of explicitly stating the type at least once when declaring a variable. I have also noticed that Python allows developers to note the type (at least when defining functions). It's not necessary and I don't think the language uses it, but at least it offers a standard mechanism to note it in the code.

If the type isn't obvious, I want the former rather than the latter.

The newest C# has the reversed inference for ctors too, so you can actually do this and not have to repeat it and still get it first.

    Person p = new();