[Hokusai]

> local type inference (var) made the language pointlessly verbose for ages

I guess that this is a question of taste.

What for you is "less verbose" for me is more confusing to read. I like to see the types as they complement variable naming. To avoid typing a few letters the code will for ever require me to double check the types with help of the IDE.

I have worked in medium sized corporate companies. The code base is quite big and one of the 20+ development teams may get transferred a project from another team (does not happens super-often, but it happens) or they may create pull-requests for bug fixes (this is more common).

Clear and easy to understand code is life saving. In one of the companies I worked for a Javascript team send a -1 instead of a "-1" the cost ramped up the hundreds of thousands of dollars and our clients were not happy about it. Rollback mechanisms were used as fast as our clients detected revenue problems on their own customers.

And the tests did not got the error as the values is used at the integration layer between our clients and us.

I see safety an increasing value as our programs control more and more money and more and more services. And, I have to admit, I feel more comfortable with more verbose code.

[vips7L]

You just need to use var properly. I.E. only when you can tell the type from the rvalue.

var a = new ArrayList<T>();

not:

var a = o.getThings();

[Hokusai]

> You just need to use var properly.

That is a very good point. I find the diamond operator more of my taste as it requires you to think if you want to expose ArrayList or List.

List<String> list = new ArrayList();

But, as you point, the second example removes information that will require to spend time to check types each time that someone reads the code. I do not like that.

I use auto-complete and I type quite fast, so, I do not see to write code as a problem. I spend most of my time understanding the functional needs, looking for better patterns or algorithms to implement performance-critical sections or finding names for exposed APIs that state clearly its function when I "write code". But, most of the time, I am just reading my old or other people's code to just change a few lines or decide on a local refactoring.

[colejohnson66]

^This

Here, the first is much less verbose, but still clear:

    var x = new Dictionary<string, MyComplexType>();
    Dictionary<string, MyComplexType> x = new Dictionary<string, MyComplexType>();

But here, it’s ambiguous what the type of `x` is without Intellisense:

    var x = y.GetStuff();

[wutwutwutwut]

Did you spend any significant time working with C#?

[Hokusai]

> Did you spend any significant time working with C#?

I have no experience with it at the corporate level. There, I have seen, it mixes a lot with .NET. So, I guess that the corporate equivalent to Java is "C#/.NET".

I spend some time several years ago with C# in Unity3D, thou.

I really liked the C# language. I found the Auto-Implemented Properties a neat compromise between encapsulation and verbosity (Verbosity has no value if does not add information).

Java is trying to be everything to everyone and that is a mistake. I liked Java more in the past, and I would have added just a few things from the past iterations of the language (e.g. Modules is a good idea that actually simplifies the language and moves much code to "frameworks" instead of being part of the core language).

C# seemed more focused on its initial style were Java is stretching all over the place.

[pjmlp]

You haven't used much LINQ, pattern matching, spans, ranges, default interface methods, non null references in C#, I guess.

[rubber_duck]

Pointless typing and verbose code has nothing to do with writing code - it's all about code being readable.

Java type declarations can be 20+ characers - just scanning through the code and having to skip all that junk makes my eyes more tired reading through. Types are implicitly deducible when you know the codebase 90% of the time (and should be added when they are not), and if you don't know the context you will be slow no matter what.

[Hokusai]

> when you know the codebase

Yes. When I was younger I worked in solo projects. I knew my code almost line by line.

In my last decade, in middle sized companies, nobody knows all the hundreds of micro-services code. And code changes while on vacation, that can be 6 weeks of the team working without you. That is not ideal, but in such a big code base it is difficult to have everyone reviewing all the changes on a single micro-service, impossible to have all 20+ teams reviewing all of each others code.

Different problems need different solutions and code styles, I guess.

[rubber_duck]

My point is that in a good code base types should be obvious from context. If you don't know the context then you will be slow (and make a lot of mistakes) no matter what the type say because you'll likely misunderstand the domain logic (context) unless it's something trivial. I would hate to work somewhere where I'm expected to randomly drop into micro services I didn't have anything to do with and debug/support them - sounds stressful.