News for hackers. Stuff that matters.

A comment on Java 10 and beyond – a look at the potential language change.

Re:Java 10 and beyond – a look at the potential language change by bitL on Sunday May 13, 2018 @05:54PM (#17061239)
Those changes seem to look like a completely new language, cross of Java/Scala/Swift - why don't they call differently, like Jalaft? The main reason to use Java was its backward compatibility. If I needed to learn a new language every 6 months, I'd learn another one to be honest.
[ Parent | on HN ]
Re:Java 10 and beyond – a look at the potential language change by elygre on Sunday May 13, 2018 @06:16PM (#17061322)
It will remain fully backward compatible. No need to use new features, and all existing code will compile.
[ Parent | on HN ]
Re:Java 10 and beyond – a look at the potential language change by ckarmann on Sunday May 13, 2018 @08:11PM (#17061786)
These are just syntactic sugar, not going to change much to the way Java programs are coded. I found these changes rather tame compared to historical ones. Java 8 (lambdas), Java 5 (generics, annotations) and Java 1.1 (inner/anonymous classes, reflection) were far more disruptive.
[ Parent | on HN ]
Re:Java 10 and beyond – a look at the potential language change by lovelle on Monday May 14, 2018 @02:04PM (#17067848)
I do not agree with that, this is not just syntactic sugar, for example in case of large 'else if' statements the complexity to choose proper branch is O(n), instead with pattern matching the chosen branch will be at constant time.
[ Parent | on HN ]
Re:Java 10 and beyond – a look at the potential language change by ckarmann on Tuesday May 15, 2018 @12:34AM (#17071673)
While the article mentions Pattern Matching, it seems to be something for the distant future. I was referring changes of Java 11, which seems to me the focus of the article.
[ Parent | on HN ]
Re:Java 10 and beyond – a look at the potential language change by lovelle on Tuesday May 15, 2018 @11:32PM (#17079831)
If I am not mistaken, Pattern matching will be included on Java 11, please correct me if I am wrong.
[ Parent | on HN ]
Re:Java 10 and beyond – a look at the potential language change by rb808 on Sunday May 13, 2018 @09:43PM (#17062102)
I agree, its a complete change in paradigm. Lots of projects are a mix of the old and new ways of doing things which is a mess. Developers too - are you a traditional style Java dev or a new style?

If it keeps going in its new direction, soon they'll just be able to name it javascript. :)

[ Parent | on HN ]
Re:Java 10 and beyond – a look at the potential language change by tytytytytytytyt on Sunday May 13, 2018 @06:04PM (#17061278)
Will it not still be backwards compatible?
[ Parent | on HN ]
Re:Java 10 and beyond – a look at the potential language change by CrendKing on Sunday May 13, 2018 @06:19PM (#17061329)
If a new language feature is available, someone in your team will start to use it, because it compiles, and code becomes shorter, so why not. And you will have to review their code daily, which forces to "relearn" the language. I think this is why OP complains.
[ Parent | on HN ]
Re:Java 10 and beyond – a look at the potential language change by nradov on Sunday May 13, 2018 @06:59PM (#17061487)
What's wrong with relearning the language? That's nothing new for developers.
[ Parent | on HN ]
Re:Java 10 and beyond – a look at the potential language change by bitL on Sunday May 13, 2018 @10:11PM (#17062205)
Why wouldn't you rather learn a new one if your old one is changing rapidly into a weaker version of some other language that did it better already? I personally don't care at all about those new things; I have them in Scala, I don't need them in Java. I can mix those two as I like anyway.

I'd much rather see type erasure fixed, as that messes up every single language based on JVM. But that would be like "the incompatible change" of a decade...

[ Parent | on HN ]
Re:Java 10 and beyond – a look at the potential language change by virtualwhys on Monday May 14, 2018 @12:23AM (#17062664)
> I'd much rather see type erasure fixed, as that messes up every single language based on JVM

What? Type erasure is one of the main reasons why the JVM is targeted by so many languages (Java, Clojure, Kotlin, Scala, Groovy, JRuby, etc.). Had the JVM gone the way of the CLR the programming language landscape would probably look a lot different than it does today.

Perhaps you mean lack of support for value types? That does affect every language running on the JVM.

[ Parent | on HN ]
Re:Java 10 and beyond – a look at the potential language change by xg15 on Monday May 14, 2018 @08:07AM (#17064725)
> Type erasure is one of the main reasons why the JVM is targeted by so many languages.

As someone who grapples with erasure as well, I haven't heard this argument before. Could you explain that?

[ Parent | on HN ]
Re:Java 10 and beyond – a look at the potential language change by rossjudson on Sunday May 13, 2018 @07:33PM (#17061615)
You're not already reviewing their code and gating change? I think you should start there.

Learning from other peoples' code is not generally considered harmful.

[ Parent | on HN ]
Re:Java 10 and beyond – a look at the potential language change by bilbo0s on Sunday May 13, 2018 @06:11PM (#17061304)
Well that's true.

I think the issue he was speaking to was that if many of the new features require doing things in a new way then it really is something new. But your point is well taken as well. C++ is still C++ whether you use standard templates or not.

[ Parent | on HN ]
Re:Java 10 and beyond – a look at the potential language change by stochastic_monk on Sunday May 13, 2018 @06:14PM (#17061313)
That's part of why it's such a nightmare to parse.

The GCC C++ parser is over a megabyte of ASCII text. Think about it: it takes over a million characters to figure out how to parse C++ code. This complexity is partially because there are so many ways to do the same thing.

All auto parameters, or make it a template? `if constexpr` or `std::enable_if_t`? Macros for generic programming or variadic variadic template templates? Overloading or specialization?

I love C++, and backwards compatibility is something that's been valuable for it, but it certainly comes with its challenges.

[ Parent | on HN ]
Re:Java 10 and beyond – a look at the potential language change by Someone on Sunday May 13, 2018 @06:59PM (#17061485)
”if many of the new features require doing things in a new way then it really is something new.”

Firstly, nothing requires you to do things in a new way.

Secondly, if “you could already do that” implies “not really something new” for a programming language, updates to the syntax of programming languages can never count as “really something new”.

[ Parent | on HN ]