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...
The curious case of the broken inverse: you won't get more type safety by having type inference, but you are likely to end up with less type safety when you are not having it ;)
I have seen no evidence of that. With that logic, Java programmers would use "Object" instead of "List" because they have fewer characters to type?
I hope they will give it second though. In Java 'var' or 'val' are not reserved keywords. It was difficult to migrate existing code when 'enum' was introduced. 'const' is reserved but nothing for variable, perhaps 'new' or some symbols.
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.
I hope this gets added to the language, we use Lombok heavily where I work and find it pretty great with it's val class that allows type inference, although it requires an explicit import and can't be used within Lambdas. The website isn't the prettiest but Lombok is a fantastic addition to a Java codebase and massively reduces the amount of boiler plate often associated with Java. A list of Lombok features https://p…
My experience is similar, however more like: Groovy === happy developers
Apache Groovy used to have the === operator in its earliest versions, but dropped it in favor of using a custom .is() method. The meaning of == is different to its use in Java, catching out many -- "happy" is not the word I'd use.
The curious case of the broken inverse: you won't get more type safety by having type inference, but you are likely to end up with less type safety when you are not having it ;)
I have seen no evidence of that. With that logic, Java programmers would use "Object" instead of "List " because they have fewer characters to type? This makes no sense.
It makes more sense after you have deliberately weakened the typing of an API because you felt that you were overstretching your co-developers (and/or your own) patience for nested angle brackets.
The basic idea is that type inference would shift the sweet spot for the right amount of typing upwards.
Hmm... I agree it looks nicer. Who's typing Java code all by hand these days, though? There various IDEs that save me all the typing. It's also nice to be able to go the declaration of a variable to see exactly what type it is - that's mostly for code not written by myself, or old code that I do not remember. For local variable that's fine (I hope we won't infer types this way for method parameters), so I guess I lik…
> Who's typing Java code all by hand these days, though? There various IDEs that save me all the typing. Reducing boilerplate mostly helps with reading code, not with writing it.
It does, my code and trail of thought is significantly different when switching to coffeescript from javascript.
> 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…
If you can explain the value of restricting a local initialized with a new instance being inferred to be an interface type, you'll have a point. You won't be able to, because there is literally no point since the constructor must be statically referenced anyway, but I'd love to see you try.
I hope this gets added to the language, we use Lombok heavily where I work and find it pretty great with it's val class that allows type inference, although it requires an explicit import and can't be used within Lambdas. The website isn't the prettiest but Lombok is a fantastic addition to a Java codebase and massively reduces the amount of boiler plate often associated with Java. A list of Lombok features https://p…
My experience is similar, however more like: Groovy === happy developers
Same here. Groovy rocks my world and is the main reason I've barely even looked at Java 8.
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.
Optional, alright, but promoting bad practices. If people like dumb-down languages, there are plenty of them already!
What are the bad practices being promoted by this? How does it qualify as dumbed down? Simply ranting about things that, charitably, you don't seem to understand, does not make the rants valid.