Hacker News Reader

Comment by temporallobe | Hacker News Reader

I’m stuck on 8 and 11 in my current projects, so I haven’t seen much of these in the field other than the new record feature. What I am really surprised about is the var construct. Honestly, this leaves me a little conflicted since it 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? I would perhaps argue against it being dynamically-typed since by definition type inference happens at runtime, but it certainly leaves Java in a sort of limbo. I don’t personally care, but I know at some point the topic will come up amongst my dev peers, at which point there will sure to be a (mostly friendly) debate.

View on HN

> 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.

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.

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.

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?).

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.

It’s just “simple” type inference.

As for what style is preferred: yeah I have also seen plenty of not so friendly debate on it, but I think it is fairly simple (and we do have “prior art”, with Scala Haskell, etc): in case the type is trivial, use var. Like new SomeLongAssClassName is a perfect candidate for var as having the typename twice doesn’t constitute any additional information. I would wager that with good method names, it can also be used for things like `obj.getLocation()`, where we happen to have a Location class as well. The other use case is when we just don’t care about the type, either because it is very complex with low info density (like a Map with a nested generic value type, which is easy to recognize from context and variable names), or because it is trivial (like I like to use things like var i = 2)

Reply on news.ycombinator.com