Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Representing the Impractical and Impossible with JDK 10 “var”

benjiweber.co.uk

Post reply on HN
Print view View original

111–120 of 131 posts

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

#111

Post by vbezhenar »

pents90 wrote: 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 don't like the fact that `var` breaks class hierarchy. I can write `List l = getList()` and then variable `l` will have only methods from `List`. If I'll decide to change `getList()` return type, it'll be easier to migrate the code. With `var` variable `l` probably will have something like `ArrayList` type and I can accidentally use methods from `ArrayList`, even if I don't really need them, tying this code to concrete class.

It's obvious that everyone will use `var` everywhere, so using `var` in one place and explicit type declaration in another probably would be even worse.

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

#112

Post by [deleted] »

spion wrote: post #72
pents90 wrote: 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…

Its so funny, watching Java fans talking about silly things like `var` whilst their language gets more obsolete every day. I'm so sorry, but basic type inference won. Can you please go away so we can get a good ecosystem and a good language (with first class support VM wise) to go with it in a single package? On a side note, its getting very tiring to rewrite the whole ecosystem every time a language is being annoyin…

[deleted]

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

#113

Post by spion »

Thiez wrote: post #73
spion wrote: post #72

Earlier quoted context omitted.

Its so funny, watching Java fans talking about silly things like `var` whilst their language gets more obsolete every day. I'm so sorry, but basic type inference won. Can you please go away so we can get a good ecosystem and a good language (with first class support VM wise) to go with it in a single package? On a side note, its getting very tiring to rewrite the whole ecosystem every time a language is being annoyin…

I'm not sure I understand your second paragraph, many (most?) JVM languages (Kotlin, Scala, Clojure) have Java interop, you can leave Java "the language" while keeping Java "the library ecosystem".

re: Clojure, the stack traces I think explain the issue (they're pretty terrible, you can see the Java guts).

With Scala its probably better, but still the impedance mismatch shows here and there (the Java ecosystem doesn't use case classes)

Not sure what the situation is with Kotlin, but I'm guessing its the best because its closest to Java semantically and made by JetBrains who pay extra attention to usability for developers.

I should've probably avoided the bitter sarcasm, but I've seen this `var` argument over and over for over 10 years now and I can't believe its still around, even when its very clear its bringing the language down (you can't name anonymous object types). Local type inference does not hurt readability since in > 90% of the cases the expression on the right side contains more than enough information for a human reader to infer the type too. This is often so pronounced that Java code looks downright silly: `Item item = x.getItem();`, `Array xes = new Array();` and so on.

Yet developers have opposed this change over and over and now that its finally getting in it feels like such a waste that it didn't happen sooner. Perhaps the ecosystem would've kept more people if it did...

Which reminded me of another waste: every time a new VM and/or language is created (like say Golang), we pour in millions of developer hours all over again re-inventing its library ecosystem. Because clearly in our new VM / language code from other ecosystems is useless junk somehow. And everyone accepts this as normal. Doesn't that ring any alarm bells in the back of our heads by this point?

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

#114

Post by kochthesecond »

vbezhenar wrote: post #24

I'm very disappointed that they didn't make `val` keyword. Very simple change but code becomes significantly more readable and a lot of bugs will be compile errors.

I am also disappointed by this, I want it to be more painful to use rebindable references than final (immutable) references.

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

#115

Post by vbsteven »

vbezhenar wrote: post #111
pents90 wrote: 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 don't like the fact that `var` breaks class hierarchy. I can write `List l = getList()` and then variable `l` will have only methods from `List`. If I'll decide to change `getList()` return type, it'll be easier to migrate the code. With `var` variable `l` probably will have something like `ArrayList` type and I can accidentally use methods from `ArrayList`, even if I don't really need them, tying this code to conc…

The problem here is not the `var` keyword but the `getList()` method that is leaking implementation details by having a concrete class return type instead of an interface.

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

#116

Post by vbsteven »

cm2187 wrote: post #68
pents90 wrote: 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…

On your point about the IDE helping you, there are two use case. object i = new object(); I agree you only type once, the IDE will suggest object after new. But in that case the type is needlessly redundant, var could be use without making the code any less readable. object i = myfunction(); Here the object is sementically useful but given that you have to type it before you type the name of the function I don't see…

For case 2, a modern IDE like IntelliJ has completion suffixes. So you can type:

myfunction().var

and it would expand to

object i = myfunction();

where i would be highlighted so you can immediately type the name of the variable and when you press enter the cursor is placed after the completed statement.

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

#117

Post by spion »

spion wrote: post #113
Thiez wrote: post #73

Earlier quoted context omitted.

I'm not sure I understand your second paragraph, many (most?) JVM languages (Kotlin, Scala, Clojure) have Java interop, you can leave Java "the language" while keeping Java "the library ecosystem".

re: Clojure, the stack traces I think explain the issue (they're pretty terrible, you can see the Java guts). With Scala its probably better, but still the impedance mismatch shows here and there (the Java ecosystem doesn't use case classes) Not sure what the situation is with Kotlin, but I'm guessing its the best because its closest to Java semantically and made by JetBrains who pay extra attention to usability for…

Should've clarified that "first class support" wasn't really about the VM but mostly about the library ecosystem.

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

#118

Post by ionised »

pents90 wrote: 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…

Can't say I'm happy about this. Type inference really doesn't belong in Java in my opinion.

Not only is it ambiguous to developers who might be maintaining the code later, I find it much worse for readability. People tend to start writing OO code like it is Javascript which is is never good.

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

#119

Post by ionised »

jayd16 wrote: post #20
pents90 wrote: 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…

Var makes refactoring way easier while being just as safe and informative.

How?

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

#120

Post by ionised »

salawat wrote: post #80
TheDong wrote: post #66

Earlier quoted context omitted.

`var address` you can also in a short matter of clicks get to the definition of address's type, whatever it is, if you have an IDE.

And what if you don't? When did programming suddenly shift away from "the programmer should be aware of what they are doing?" Hell, I can't count the number of times I've had to troubleshoot bad imports/classpath management brought about by some genius letting his IDE do his thinking for him.

> When did programming suddenly shift away from "the programmer should be aware of what they are doing?"

When Javascript became ubiquitous.

Post reply on HN