Hacker News Reader

Comment by dunefox | Hacker News Reader

> seems to be antithetical to the principles of a strongly-typed language. So does this now reclassify Java as a weakly- or dynamically-typed language?

Var and type inference are neither antithetical to static typing nor do they make a language dynamically typed. They're antithetical to the verboseness of Java.

View on HN

Java is not usually considered to be a statically-typed language and I was not implying that it was. And the definition of dynamic typing is somewhat vague to me, although allowing unspecified type inference is somewhat dynamic, even though one cannot reassign the variable to a different type at a later point.

And my point about was that Java was designed to be verbose, except that now “var” breaks this verboseness. I am sure there was plenty debate on this topic already, but I thought it would be interesting to reason about how this changes the character and perception of Java.

> Java is not usually considered to be a statically-typed language

Java is absolutely considered a statically typed language. Compare it to Python and CL, then you know what the difference is.

Except that having the type info is really, really useful at the call site. I know the IDE is able to infer it and display it but it's still a pain to see all the vars during a code review in a browser.

Agree, it's a straight up reduction in code readability for all future maintainers so a single original developer can avoid doing a thing their IDE probably would do for them automatically. (I use "introduce variable" to create most variables automatically of the correct type).

Yes I know the IDE can also reveal what type a var is, but you generally read code in lots of places that aren't IDE enabled.

It also adds more work for the compiler. I'm not sure the effect on Java compile types yet but Kotlin and Swift have both suffered from slow compile times and this seems to be a factor.

I'm guessing that most of the larger codebases out there will add "no var allowed" to their style guides within the next few years.

var shouldn’t increase compilation time in any meaningful way. The compiler has to figure out the type anyway (otherwise, how would you get type errors?).

It’s not an either-or thing though. I prefer defaulting to vars and changing specific variable definitions to show explicit types based on the right hand side expression. These “no var allowed” and friend global rules are almost always bad (looking at the myriad c++ rules) —- there are cases where it will make code more readable and others where the traditional style is the preferred.

Yeah I'm not sure where this originated (recent C++ has something similar with auto and I think C# now has var as well) but if I'm doing a code review rather than writing code in an IDE, var is a bit of a hindrance.

It's not the IDE, it's the compiler that infers it. So type information is always available.

That's not the point - try having 2 or 3 way diff, pull request with just var. It's =awful=. I know most of the standard APIs (incl. overloaded methods and what not) by heart but not every little function and class in a million lines of code project.

To me var adding is mosttly an anti-feature - when using an IDE, I dont even bother to declare the stuff, it gets auto completed. When I read code outside the IDE - well it sucks. It's not the level of 'perl - write only', but at least it aspires to be.

Reply on news.ycombinator.com