Live data from Hacker News

Representing the Impractical and Impossible with JDK 10 “var”

benjiweber.co.uk

21–30 of 131 posts

Re: Representing the Impractical and Impossible with JDK 10 “var”

#21
post #2

While I submitted this, I would like to voice my opinion that I am against "var" in Java. People may ask, "Why should I have to enter in the type if the compiler can infer it for me?" My answer is twofold: 1) You or some other maintainer will need to know what that type is later when reading the code. Of course, "var" is meaningless, requiring you to dig back one or more steps to determine the actual type. 2) You don…

What are your opinions about python, as it has no explicit type for readability.

Not the poster, but my vote would be that it gets far more credit for readability than it deserves.

The dynamic nature helps a fair bit for some actual readability. But in large, I think it is more good marketing and a loud opinion that it is readable that makes people think it is readable.

Re: Representing the Impractical and Impossible with JDK 10 “var”

#22
post #18
post #12

Earlier quoted context omitted.

Reading long nested generic type declarations in Java is an absolute utter mental pain. Being able to vat that shit will be a god send.

Then you're dealing with long, nested invisible type declarations.

Yes. By not having them there makes them easier to read and understand. Seriously.

It is often the case that very simple stream operations end with ludicrously complex type signatures. By being able to var them it makes them far simpler to read.

Re: Representing the Impractical and Impossible with JDK 10 “var”

#23
post #2

While I submitted this, I would like to voice my opinion that I am against "var" in Java. People may ask, "Why should I have to enter in the type if the compiler can infer it for me?" My answer is twofold: 1) You or some other maintainer will need to know what that type is later when reading the code. Of course, "var" is meaningless, requiring you to dig back one or more steps to determine the actual type. 2) You don…

Any sufficiently sharp tool can cut deeply in the hands of the untrained. The answer isn't to dullen our blades, it's to find better apprentices and journeyman to work with.

Re: Representing the Impractical and Impossible with JDK 10 “var”

#25
post #2

While I submitted this, I would like to voice my opinion that I am against "var" in Java. People may ask, "Why should I have to enter in the type if the compiler can infer it for me?" My answer is twofold: 1) You or some other maintainer will need to know what that type is later when reading the code. Of course, "var" is meaningless, requiring you to dig back one or more steps to determine the actual type. 2) You don…

> You or some other maintainer will need to know what that type is later when reading the code.

The Microsoft rule is to only use var when the type is obvious from the assignment. That essentially boils down to new, cast and anonymous types.

Re: Representing the Impractical and Impossible with JDK 10 “var”

#26
post #2

While I submitted this, I would like to voice my opinion that I am against "var" in Java. People may ask, "Why should I have to enter in the type if the compiler can infer it for me?" My answer is twofold: 1) You or some other maintainer will need to know what that type is later when reading the code. Of course, "var" is meaningless, requiring you to dig back one or more steps to determine the actual type. 2) You don…

What are your opinions about python, as it has no explicit type for readability.

I’m only an amateur Python programmer so grain of salt please.

Python is excellent at being intuitive and readable for the original programmer or when you’re skimming the code looking for broad logic.

Not so much for the maintainer. The programmer needs to keep a lot of state in their head to make up for the type system. If you don’t have good tests, it is even harder.

Re: Representing the Impractical and Impossible with JDK 10 “var”

#27
post #2

While I submitted this, I would like to voice my opinion that I am against "var" in Java. People may ask, "Why should I have to enter in the type if the compiler can infer it for me?" My answer is twofold: 1) You or some other maintainer will need to know what that type is later when reading the code. Of course, "var" is meaningless, requiring you to dig back one or more steps to determine the actual type. 2) You don…

There is no appreciable performance hit for locally inferred types given that the compiler isn’t doing much. Globally inferred types can take a hit, though most of those are based on Hindley Milner which can be pretty efficient.

Re: Representing the Impractical and Impossible with JDK 10 “var”

#28
post #2

While I submitted this, I would like to voice my opinion that I am against "var" in Java. People may ask, "Why should I have to enter in the type if the compiler can infer it for me?" My answer is twofold: 1) You or some other maintainer will need to know what that type is later when reading the code. Of course, "var" is meaningless, requiring you to dig back one or more steps to determine the actual type. 2) You don…

I quite like type inference in typed languages (e.g. Go, Kotlin etc), and when I read about it coming to Java I wasn't that fussed, just saw it as a nice to have.

It didn't occur to me before I read this post that the complex, chained generic types that you can sometimes get with "builder" like patterns (e.g. SQL generators) can become incredibly complex, so this would tidy that up quite nicely

Re: Representing the Impractical and Impossible with JDK 10 “var”

#29
It's one of the things I really missed when going from C# to Java, but with IntelliJ, the typing experience is very similar from C#.

Imagine I want to have a variable like:

     Person p = new Person("John");
All I would type in IntelliJ is:

     new Person("John").var
After pressing "tab", that will autocomplete for me and put the focus on the variable name so I can rename it from the default inferred value.
Post reply on HN