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

71–80 of 132 posts

Re: JEP 286: Local-Variable Type Inference

#71

Post by vbezhenar »

vorg wrote: post #63
vbezhenar wrote: post #56

Java loses its explicitness with each release. And it's still much worse as a language than Scala, Kotlin, Groovy, Ceylon (and probably always will be behind). I don't see much value in those improvements. If one wants a better Java, he can use it right now. What Java needs is JVM improvements, like value types or full support for bytecode hot reload. Java 1.4 was very minimalistic and beautiful language. I liked it…

> it's still much worse as a language than Scala, Kotlin, Groovy, Ceylon Some of those languages are better than each other, and they are much worse languages than Clojure, another JVM-hosted language you ignored.

Clojure is very different language, and I don't know it well, so I didn't include it. Of course it's not a closed list.

Re: JEP 286: Local-Variable Type Inference

#72

Post by gclaramunt »

incepted wrote: post #44
greydius wrote: post #42

Earlier quoted context omitted.

All we need is higher kinded types and implicits.

Higher Kinded Types, yes, but implicits... Yuck. Scala has definitely proven them as a failed experiment, I hope we will never seem them again in languages going forward.

unless, you're proposing a global implicits dictionary a-la Haskell, leave them alone, I much prefer to give up subtyping...

Re: JEP 286: Local-Variable Type Inference

#73

Post by stygiansonic »

The approach taken to preserve backwards compatibility with existing code that already uses `var` as an identifier is interesting:

"The identifier var will not be made into a keyword; instead it will be a reserved type name. This means that code that uses var as a variable, method, or package name will not be affected; code that uses var as a class or interface name will be affected (but these names violate the naming conventions.)"

I didn't know there were such things as "reserved type names", but I'm guessing `var` will be treated sort of like `String` or `Object` (always available without an explicit import) and maybe it'll be a class in `java.lang`?

Seems like a much "nicer" approach than when Enum types were introduced with the `enum` keyword, but I guess that was slightly different.

Re: JEP 286: Local-Variable Type Inference

#74

Post by TazeTSchnitzel »

stygiansonic wrote: post #73

The approach taken to preserve backwards compatibility with existing code that already uses `var` as an identifier is interesting: "The identifier var will not be made into a keyword; instead it will be a reserved type name. This means that code that uses var as a variable, method, or package name will not be affected; code that uses var as a class or interface name will be affected (but these names violate the namin…

PHP recently did the same thing with PHP 7, which introduced type declarations for the scalar types. This meant we needed to reserve `int`, `float`, `string` and `bool`. To minimise backwards-compatibility breakage, we only reserved these as class/interface/trait names, and not in other contexts.

And it seems we were right to reduce the scope of it. PHP 7 prohibiting "String" as a class name ended up being a significant BC break affecting several projects. I imagine it might have been worse still if `string` was a reserved word.

Re: JEP 286: Local-Variable Type Inference

#75

Post by Others »

vivin wrote: post #6

This is pretty nice. Hope it goes through. It's about time that we had local-variable inference in Java. It does mean that the diamond can't be used this way: var list = new ArrayList (); There is no way to infer the type of the generic parameter. So we will go back to doing: var list = new ArrayList (); Which isn't a big deal IMO because the generic parameters had to be specified on the LHS anyway to use the diamond…

As far as val vs let goes, I actually prefer val, because it has symmetry with var. That is to say "variable foo" is more similar to "value foo" than "let foo," since "value" is an adjective like "variable". Of course, I suppose this is personal preference.

Re: JEP 286: Local-Variable Type Inference

#76

Post by Others »

nikolay wrote: post #47
merb wrote: post #8

var + val would be great.

Yeah, let's spread the nonsense further! There are constants and variables; values are something else. Just because "val" is a short abbreviation everybody gets, it doesn't mean we should abuse it!

I disagree with that sentiment. Constant to me implies decided at compile time. The reason we should use "val" is because it is a short abbreviation everybody gets. It also has symmetry with "var," as "value" and "variable" are both adjectives, whereas "let" is a verb.

Re: JEP 286: Local-Variable Type Inference

#77

Post by Others »

incepted wrote: post #44
greydius wrote: post #42

Earlier quoted context omitted.

All we need is higher kinded types and implicits.

Higher Kinded Types, yes, but implicits... Yuck. Scala has definitely proven them as a failed experiment, I hope we will never seem them again in languages going forward.

I really like Scala. It is a really interesting language, and a productive one for me to program in. However, I agree that implicits are a bad feature. 90% of the confusing bits of Scala are because implicits exist and are, well, implicit.

Re: JEP 286: Local-Variable Type Inference

#78

Post by acjohnson55 »

incepted wrote: post #44
greydius wrote: post #42

Earlier quoted context omitted.

All we need is higher kinded types and implicits.

Higher Kinded Types, yes, but implicits... Yuck. Scala has definitely proven them as a failed experiment, I hope we will never seem them again in languages going forward.

Implicits are tricky, but they are the best way I know of to solve the problems they do. Other languages (JavaScript, Swift, etc.) have essentially open classes, where attachment of additional functionality to a type impacts a program globally. Implicits make it much easier to scope these extensions.

They are also quite useful for wiring up context (take Akka's ActorSystem, for example) at the declaration level, so that the bodies of your classes and functions only explicitly talk about your domain objects, rather than framework machinery.

They're also a big part of the power behind projects like Shapeless, which are quite useful for scrapping boilerplate.

Most controversially, they are also used to implement implicit type conversions. Modern idiomatic Scala discourages this, but it can sometimes be helpful.

Re: JEP 286: Local-Variable Type Inference

#79

Post by jonsterling »

PantaloonFlames wrote: post #58

Welcome to 2007? C# added implicitly typed local variables (and the var statement) to the language 9 years ago. https://msdn.microsoft.com/en-us/library/bb308966.aspx

Welcome to 1972, actually! https://en.wikipedia.org/wiki/Logic_for_Computable_Functions

Re: JEP 286: Local-Variable Type Inference

#80

Post by acjohnson55 »

The reaction here is indicative of why I'm starting to consider whether maybe it's best that Java stays Java. Sure, I'd personally be really annoyed typing super redundant type declarations everywhere. But then again, I wouldn't have to, because I'd simply use Scala, because it's more expressive. But a lot of people clearly love good old verbose Java.

Java has been super slow to adopt things that are more or less the norm in other popular languages. Why bother at this point? Isn't Kotlin a pretty good sugared-up Java, anyway?

Lightbend (caretakers of Scala, Play Framework, Akka, Spark, Slick, SBT, and others) wisely announced their dedication to both Scala and Java. It's caused a big stir in the community, but it kind of seems like that should make everybody happy. They're two ecosystems geared to serious software, built on a solid platform, but with very different constituencies. Lightbend realized there's no point in pressuring people to adopt Scala. People will do it on their own, if they want to. But with strong support of both languages, they can address a very broad swath of the development world.

Post reply on HN