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

81–90 of 131 posts

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

#81

Post by trixie_ »

gravypod wrote: post #75
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'm glad that I'm not the only one in the Java community who is extremely against `var`-like constructs. Large type inference is an anti-pattern. People usually fight this with "why would I need to type it if the compiler can figure it out!?" but those people don't understand the cardinal rule of software engineering: code is not for the compiler or the computer to understand, it is for the programmers to understand.…

See the example of

Account account = customer.GetAccount();

List transactions = account.GetTransactions();

Have I saved you any extra-effort here by specifying the types? You have no idea where these types came from or how they are defined. So why is this useful? 'Go to definition' works just as well on var.

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

#82

Post by kinghajj »

walshemj wrote: post #67

Can some explain the fist example says infers the type is right there in black and white var foo = new ArrayList (); It literally says exactly what foo is !!

Yes, but in current Java one would have to write

ArrayList foo = new ArrayList()

Or, at least

List foo = new ArrayList()

Whereas with `var`, as you show, the compiler infers the type. Proponents of this point out exactly what you did: the type is right there, so why should the programmer have to write it twice?

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

#83

Post by exabrial »

My opinion is it you have the time to declare a variable, then you have the time to hit control-space to put the type. Not putting the type communicates less information to the next guy. If you "don't care" about the type, then why are you declaring a variable in the first place? Just chain the call.

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

#84

Post by dnomad »

trixie_ wrote: post #81
gravypod wrote: post #75

Earlier quoted context omitted.

I'm glad that I'm not the only one in the Java community who is extremely against `var`-like constructs. Large type inference is an anti-pattern. People usually fight this with "why would I need to type it if the compiler can figure it out!?" but those people don't understand the cardinal rule of software engineering: code is not for the compiler or the computer to understand, it is for the programmers to understand.…

See the example of Account account = customer.GetAccount(); List transactions = account.GetTransactions(); Have I saved you any extra-effort here by specifying the types? You have no idea where these types came from or how they are defined. So why is this useful? 'Go to definition' works just as well on var.

That code is much more scannable. The ability to scan code, to quickly glance at a method or a class and grok it in under 30 seconds is paramount. In large projects I've worked on any code that fails the 30-second test is immediately rejected at code review. Having to hover over every variable to see the types will make scanning such code in an ide a very tedious process. It will make most code review tools (that don't support such functionality) much, much less useful. I fear for the 30-second test and scanning code.

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

#85

Post by stickfigure »

rmrfrmrf wrote: post #69
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…

> any competent IDE can do it for you. My biggest gripe with Java by far is the implied IDE requirement.

The IDE is Java's biggest strength, and it matters.

I've worked with plenty of engineers who are absolute masters of vim and emacs; their fingers fly on the keyboard. It looks impressive but even the best of these people look like rank amateurs compared to the people who have spent equivalent time mastering IDEA or Eclipse. With a good IDE the code practically writes itself. This is a real productivity gain, and needs to be considered as part of the value proposition of the language/environment.

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

#86

Post by exabrial »

trixie_ wrote: post #16
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'm pro var * I write code a lot more fluidly with var. When I go back to writing non-var code (enforced by some departments) I find that it breaks my focus on solving the problem at hand. I end up writing my code with var and then going back and replacing my vars with the type names. * I find code a lot easier to read. I can understand the flow of the logic easier, the variable names are enough. Unless you have the…

I think my productivity [temporarily] goes up, but my coworkers' productivity [always] goes down, when using dynamic and untyped stuff.

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

#87

Post by stickfigure »

kinghajj wrote: post #82
walshemj wrote: post #67

Can some explain the fist example says infers the type is right there in black and white var foo = new ArrayList (); It literally says exactly what foo is !!

Yes, but in current Java one would have to write ArrayList foo = new ArrayList () Or, at least List foo = new ArrayList () Whereas with `var`, as you show, the compiler infers the type. Proponents of this point out exactly what you did: the type is right there , so why should the programmer have to write it twice?

Because nobody actually writes this twice.

n,,A,r,L,,S,t,r,,Cmd-Option-V,

The IDE autocompletes everything, extract-to-variable does most of the heavy lifting.

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

#88

Post by heavenlyblue »

dnomad wrote: post #84
trixie_ wrote: post #81

Earlier quoted context omitted.

See the example of Account account = customer.GetAccount(); List transactions = account.GetTransactions(); Have I saved you any extra-effort here by specifying the types? You have no idea where these types came from or how they are defined. So why is this useful? 'Go to definition' works just as well on var.

That code is much more scannable. The ability to scan code, to quickly glance at a method or a class and grok it in under 30 seconds is paramount. In large projects I've worked on any code that fails the 30-second test is immediately rejected at code review. Having to hover over every variable to see the types will make scanning such code in an ide a very tedious process. It will make most code review tools (that don…

Modern IDEs automatically prepend shaded type annotations for types with var. I don't believe that's an issue.

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

#89

Post by stickfigure »

trixie_ wrote: post #81
gravypod wrote: post #75

Earlier quoted context omitted.

I'm glad that I'm not the only one in the Java community who is extremely against `var`-like constructs. Large type inference is an anti-pattern. People usually fight this with "why would I need to type it if the compiler can figure it out!?" but those people don't understand the cardinal rule of software engineering: code is not for the compiler or the computer to understand, it is for the programmers to understand.…

See the example of Account account = customer.GetAccount(); List transactions = account.GetTransactions(); Have I saved you any extra-effort here by specifying the types? You have no idea where these types came from or how they are defined. So why is this useful? 'Go to definition' works just as well on var.

This is a poor argument for var. Competent Java programmers use the extract-to-variable keybinding (Cmd-Opt-V in my environment); it even guesses the variable name correctly.

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

#90

Post by heavenlyblue »

stickfigure wrote: post #85
rmrfrmrf wrote: post #69

Earlier quoted context omitted.

> any competent IDE can do it for you. My biggest gripe with Java by far is the implied IDE requirement.

The IDE is Java's biggest strength, and it matters. I've worked with plenty of engineers who are absolute masters of vim and emacs; their fingers fly on the keyboard. It looks impressive but even the best of these people look like rank amateurs compared to the people who have spent equivalent time mastering IDEA or Eclipse. With a good IDE the code practically writes itself. This is a real productivity gain, and need…

I think vim/emacs vs. IDE debate is similar to that playing shooters on console vs. desktop: there's no way a joystick (a control with relative position control) could be replaced with a mouse (a control with an absolute position control) with no loss of functionality.
Post reply on HN