Representing the Impractical and Impossible with JDK 10 “var” • Hacker News Board

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

#91

Post by exabrial » Mon, Mar 05, 2018, 1:22 AM UTC

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.

Yes? I'm fairly certain you used their account to get an ordered list of their transactions.

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

#92

Post by trixie_ » Mon, Mar 05, 2018, 1:35 AM UTC

stickfigure wrote: post #89

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.

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.

Having the type name doesn't tell you anything about the type itself. Unless you have the type definition memorized, having the type declaration there is not very useful.

If I replaced the types above with var, you would still be in the dark as to what an Account and/or Transaction is without going to the type definition.

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

#93

Post by trixie_ » Mon, Mar 05, 2018, 1:37 AM UTC

exabrial wrote: post #91

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.

Yes? I'm fairly certain you used their account to get an ordered list of their transactions.

That exact statement could be said if there were no type definitions there. So what is the point?

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

#94

Post by trixie_ » Mon, Mar 05, 2018, 1:38 AM UTC

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…

I find it much easier to scan code that uses var. Type definitions (sometimes incredibly verbose) do not help readability. And knowing the name of the type is not the same as 'knowing' the type. You still need to go to the type's definition to know what it is. Unless you have all the types in your application memorized.

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

#95

Post by gravypod » Mon, Mar 05, 2018, 1:48 AM UTC

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 is one thing. This example from the post is another:

    var customerOrderGroups =
       from(customerList)
       .select(c -> tuple(
           c.companyName(),
           from(c.orders())
               .groupBy(o -> o.orderDate().year())
               .select(into((year, orders) -> tuple(
                   year,
                   from(orders)
                       .groupBy(o -> o.orderDate().month())
               )))
       ));

Yuck! I need to read that entire thing to have any clue as to what that produces or how I should go about using it. It is compact but it is not understandable. The "Magic" of Java is clean abstractions with no voodoo. PHP/Ruby programmers like their frameworks who hide code from the developer, which layer on complexity, and which "just work" (until they stop). In a proper Java project anyone can visually see, in any part of the program, what is attempting to be done and what is being linked up to what. A big portion of this is types.

    Account account = ...;
    List transactions = ...;

Is all you need to read from your example. If we were to expand your ideal to a function it would look like this:

   void someFunction(var customer) {
       var account = customer.GetAccount();
       var transactions = account.GetTransactions() 
   }

I can honestly tell you that it is impossible for me to know what will happen in this program unless I go through and look at every single code path that reaches this function. Once you have entire functions, or units of code, that are using `var` it becomes entirely unmanageable. Is a string getting into `someFunction`? What about a `Trader` or a `Banker` making it's way into there rather than a `Customer`? Would you know this was happening as both Trader and Banker implement .GetAccount()?

It's no surprise though that in the world of null-propagation haven that the language maintainers would decide to expand this class of problem to all object types! Why should the null primitive be the only thing that gets to ruin our day?

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

#96

Post by makecheck » Mon, Mar 05, 2018, 1:48 AM UTC

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 OK with implicit typing when the real type is “nearby”. For instance, if 2 lines away I see “Array of ObnoxiouslyLongTypeName”, I gain nothing by having to restate ObnoxiouslyLongTypeName for an iteration loop on that array. Similarly, a method or variable name may strongly hint at what it is.

Also, verbosity in programming is definitely a hindrance to maintenance. It’s generally easier to understand what’s there when you can remove some noise.

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

#97

Post by exabrial » Mon, Mar 05, 2018, 2:00 AM UTC

trixie_ wrote: post #93

exabrial wrote: post #91

Earlier quoted context omitted.

Yes? I'm fairly certain you used their account to get an ordered list of their transactions.

That exact statement could be said if there were no type definitions there. So what is the point?

I'm sorry but you are plain wrong.

var transactions = account.getTransactions();

...tells you nothing. Is transactions iterable? Is it an enum? Is it ordered? Are duplicates allowed? Maybe you're returning a basic type? Maybe it's another pojo?

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

#98

Post by trixie_ » Mon, Mar 05, 2018, 2:08 AM UTC

exabrial wrote: post #97

trixie_ wrote: post #93

Earlier quoted context omitted.

That exact statement could be said if there were no type definitions there. So what is the point?

I'm sorry but you are plain wrong. var transactions = account.getTransactions(); ...tells you nothing. Is transactions iterable? Is it an enum? Is it ordered? Are duplicates allowed? Maybe you're returning a basic type? Maybe it's another pojo?

The type definition alone wouldn't tell you if it's an enum, ordered, or no duplicates allowed...

The writer would know what type they're working with through intellisense. The reader would know it's iterable based on just reading the code that follows it..

So again, what does the type info give you? Most of what you mentioned you wouldn't be able to figure out from just a type name...

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

#99

Post by trixie_ » Mon, Mar 05, 2018, 2:11 AM UTC

gravypod wrote: post #95

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 is one thing. This example from the post is another: var customerOrderGroups = from(customerList) .select(c -> tuple( c.companyName(), from(c.orders()) .groupBy(o -> o.orderDate().year()) .select(into((year, orders) -> tuple( year, from(orders) .groupBy(o -> o.orderDate().month()) ))) )); Yuck! I need to read that entire thing to have any clue as to what that produces or how I should go about using it. It is com…

'var customer' as a function parameter? You're confusing dynamic typing with inferred typing.

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

#100

Post by trixie_ » Mon, Mar 05, 2018, 2:19 AM UTC

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.

Making it harder to program is not synonymous with making the programmer 'more aware'. I'd argue the opposite. It's much harder to figure out the source of or find all references of something without an IDE. An IDE with intellisense makes the programmer much more aware of what his/her options and navigate large code bases quickly.

String searching text files for definitions or references is just crude.