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

JEP 286: Local-Variable Type Inference

openjdk.java.net

Post reply on HN
Print view View original

41–50 of 132 posts

Re: JEP 286: Local-Variable Type Inference

#41

Post by wtetzner »

incepted wrote: post #38
freekh wrote: post #24

I hope this goes through! A while back, I was trying to explain in what ways Scala is more typesafe than Java for a friend (which was one argument to why I prefer Scala so much), and ended up realizing how important type inference is in this regard. The reason was this: quite often type signatures correctly modelling a domain ends up being pretty hard to read. In a good and proper API, this happens in particular when…

> A while back, I was trying to explain in what ways Scala is more typesafe than Java for a friend (which was one argument to why I prefer Scala so much), and ended up realizing how important type inference is in this regard. Type inference has absolutely nothing to do with type safety. Programming languages don't become more or less statically type safe depending on whether they support type inference. Type inferenc…

I think his argument is that without type inference, programmers will avoid more complex types, and therefor model their domain with less precise types.

Re: JEP 286: Local-Variable Type Inference

#43

Post by SideburnsOfDoom »

ygra wrote: post #40
dloose wrote: post #30

Earlier quoted context omitted.

See Brian Goetz's talk on language stewardship ( https://www.youtube.com/watch?v=2y5Pv4yN0b0 ). I'm sure nobody wants to add new and interesting features to Java more than the people who work on the language every damn day, but they've made a strong commitment to the community to not break existing code.

C# shows pretty compellingly that adding features does not have to break existing code. For example, you can use every keyword added after 1.0 as identifier, too.

But it can make things more complex too. e.g. I recently learned that the main reason that asynchronous C# methods have to be declared "async" is so that the compiler knows that in the method body, "await" is a keyword. Without this backward compatibility requirement, it could be inferred from the return type + the presence of 1 or more "await" keywords.

Re: JEP 286: Local-Variable Type Inference

#45

Post by freekh »

incepted wrote: post #38
freekh wrote: post #24

I hope this goes through! A while back, I was trying to explain in what ways Scala is more typesafe than Java for a friend (which was one argument to why I prefer Scala so much), and ended up realizing how important type inference is in this regard. The reason was this: quite often type signatures correctly modelling a domain ends up being pretty hard to read. In a good and proper API, this happens in particular when…

> A while back, I was trying to explain in what ways Scala is more typesafe than Java for a friend (which was one argument to why I prefer Scala so much), and ended up realizing how important type inference is in this regard. Type inference has absolutely nothing to do with type safety. Programming languages don't become more or less statically type safe depending on whether they support type inference. Type inferenc…

Hmmm. Yes, you're right. Typesafe is probably the wrong word to describe this according to you and wikipedia :)

The problem I tried to describe though is how feasible/typical/normal? it is to catch more or less (type) errors on compile time... Like here, where I basically my point is that it is too hard to use Java's type system to it's full extent because it becomes too cumbersome to actually use it on the callsite.

Re: JEP 286: Local-Variable Type Inference

#46

Post by nikolay »

dloose wrote: post #29
andyfleming wrote: post #4

This would definitely be a nice language feature to see in Java. It's one (of many) of the reasons I'm attracted to Kotlin ( https://kotlinlang.org/ ).

Ceylon ( http://ceylon-lang.org ) has it too! Sorry. I just like Ceylon

With all the fuzz behind Kotlin, just because JetBrains, I am surprised that Ceylon has so little awareness! Ceylon, which has great features, multiple compilation targets (can't wait for the LLVM backend), has a great entity backing it (Red Had), and is created by a celebrity (at least in the Java world) developer (Gavin King)!

Re: JEP 286: Local-Variable Type Inference

#48

Post by freekh »

wtetzner wrote: post #41
incepted wrote: post #38

Earlier quoted context omitted.

> A while back, I was trying to explain in what ways Scala is more typesafe than Java for a friend (which was one argument to why I prefer Scala so much), and ended up realizing how important type inference is in this regard. Type inference has absolutely nothing to do with type safety. Programming languages don't become more or less statically type safe depending on whether they support type inference. Type inferenc…

I think his argument is that without type inference, programmers will avoid more complex types, and therefor model their domain with less precise types.

Yup :) The comment is valid though: you don't get more type safety because of type inference. Thus saying it gets more typesafe is probably wrong...

Re: JEP 286: Local-Variable Type Inference

#49

Post by haffla »

namelezz wrote: post #33
msbarnett wrote: post #13

Earlier quoted context omitted.

> I doubt if it's a good idea in practice since you can end up with unreadable code when integrating with third party APIs. This works perfectly fine in practice as can be seen using comparable constructs in C#, C++, and many other mainstream languages. If anything it's more readable, since your code isn't littered with redundant type info.

> If anything it's more readable, since your code isn't littered with redundant type info. I fail to see the redundant type info. Example 1: int maxWeight = blocks.stream() .filter(b -> b.getColor() == BLUE) .mapToInt(Block::getWeight) .max(); "int" is not redundant type info here. Example 2: List list = new ArrayList (); // (1) var list = new ArrayList (); // (2) Many would say List in (1) is redundant but I would a…

You fail to see that type inference is optional. So yes for readability's sake, in your first example I wouldn't omit the "int", but in simpler cases you CAN omit if you want. And that's just nice, end of story.

Re: JEP 286: Local-Variable Type Inference

#50

Post by nikolay »

namelezz wrote: post #33
msbarnett wrote: post #13

Earlier quoted context omitted.

> I doubt if it's a good idea in practice since you can end up with unreadable code when integrating with third party APIs. This works perfectly fine in practice as can be seen using comparable constructs in C#, C++, and many other mainstream languages. If anything it's more readable, since your code isn't littered with redundant type info.

> If anything it's more readable, since your code isn't littered with redundant type info. I fail to see the redundant type info. Example 1: int maxWeight = blocks.stream() .filter(b -> b.getColor() == BLUE) .mapToInt(Block::getWeight) .max(); "int" is not redundant type info here. Example 2: List list = new ArrayList (); // (1) var list = new ArrayList (); // (2) Many would say List in (1) is redundant but I would a…

I agree. "var" as proposed is dumbing down Java. If there's an intelligent way to infer the interface, not the implementation, then I'd accept it, but otherwise, it's the JavaScriptification if Java given most IDEs can autocomplete this and let you correct if they assume wrongly.
Post reply on HN