Hacker News Reader

Comment by bitL | Hacker News Reader

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.

View on HN

It will remain fully backward compatible. No need to use new features, and all existing code will compile.

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.

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.

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.

If I am not mistaken, Pattern matching will be included on Java 11, please correct me if I am wrong.

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. :)

Will it not still be backwards compatible?

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.

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.

”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”.

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.

What's wrong with relearning the language? That's nothing new for developers.

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...

> 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.

> 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?

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.

Reply on news.ycombinator.com