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

New language features since Java 8 to 17

advancedweb.hu

Post reply on HN
Print view View original

291–300 of 358 posts

Re: New language features since Java 8 to 17

#291

Post by kaba0 »

temporallobe wrote: post #114

I’m stuck on 8 and 11 in my current projects, so I haven’t seen much of these in the field other than the new record feature. What I am really surprised about is the var construct. Honestly, this leaves me a little conflicted since it seems to be antithetical to the principles of a strongly-typed language. So does this now reclassify Java as a weakly- or dynamically-typed language? I would perhaps argue against it be…

It’s just “simple” type inference.

As for what style is preferred: yeah I have also seen plenty of not so friendly debate on it, but I think it is fairly simple (and we do have “prior art”, with Scala Haskell, etc): in case the type is trivial, use var. Like new SomeLongAssClassName is a perfect candidate for var as having the typename twice doesn’t constitute any additional information. I would wager that with good method names, it can also be used for things like `obj.getLocation()`, where we happen to have a Location class as well. The other use case is when we just don’t care about the type, either because it is very complex with low info density (like a Map with a nested generic value type, which is easy to recognize from context and variable names), or because it is trivial (like I like to use things like var i = 2)

Re: New language features since Java 8 to 17

#292

Post by kaba0 »

matt2000 wrote: post #228
abraxas wrote: post #214

Earlier quoted context omitted.

Except that having the type info is really, really useful at the call site. I know the IDE is able to infer it and display it but it's still a pain to see all the vars during a code review in a browser.

Agree, it's a straight up reduction in code readability for all future maintainers so a single original developer can avoid doing a thing their IDE probably would do for them automatically. (I use "introduce variable" to create most variables automatically of the correct type). Yes I know the IDE can also reveal what type a var is, but you generally read code in lots of places that aren't IDE enabled. It also adds mo…

It’s not an either-or thing though. I prefer defaulting to vars and changing specific variable definitions to show explicit types based on the right hand side expression. These “no var allowed” and friend global rules are almost always bad (looking at the myriad c++ rules) —- there are cases where it will make code more readable and others where the traditional style is the preferred.

Re: New language features since Java 8 to 17

#293

Post by pjmlp »

hota_mazi wrote: post #167
pjmlp wrote: post #127

Earlier quoted context omitted.

Pity that Kotlin builds on Java ecosystem and uses that as selling point for adoption. Kotlin libraries on the JVM cannot take advantage of JVM ecosystem, and require KMM to be portable across runtimes, or be constrained to the Android Java flavour. It is like having a flavour of Typescript that only works on Edge.

> Kotlin libraries on the JVM cannot take advantage of JVM ecosystem This makes literally no sense since Android apps are built using not just Gradle but actually the entire Maven Central repo that all Java apps use. Without any changes. If what you said was remotely close to accurate, Android would have its own Maven Central repo.

Without any changes!

Ah the Google's advocate at his best.

Lets not show the people that the libraries that happen to work are those that match Android Java capabilities.

Please show us how to use a possible Java 14 library from Maven Central on Android, using records or Panama interop.

Re: New language features since Java 8 to 17

#294

Post by kaba0 »

Athas wrote: post #164
brundolf wrote: post #98

Earlier quoted context omitted.

Counterpoint: it's become a fairly multi-paradigm language at this point, and a multi-paradigm language is exactly what should be the defacto language in curriculums Whether or not Java is the best one for this purpose is up for debate, but I think it's no longer a bad one

> Counterpoint: it's become a fairly multi-paradigm language at this point, and a multi-paradigm language is exactly what should be the defacto language in curriculums I'm surprised you would say this, as it is the exact opposite of my experience as university teacher. I think we should teach concepts , and concepts appear much more crisply in small and focused languages. I think students gain more from being exposed…

I agree with you - so teach both Java (for OOP) and Haskell (for FP). But I do find Java a perfect candidate for teaching about “traditional” development, where students get the benefit of static typing with easy to digest error messages (not that much runtime failure in specific circumstances that is really hard to debug as a beginner), well-defined behavior all-around (okay, not with regards to concurrency but that’s another topic — but not having your program segfault is very useful), understanding lower level memory details is in my opinion easier tacked on knowledge of a higher level language, so GC is a great start, and all around an easy/small language where the language primitives can be built upon in basically every other language.

Re: New language features since Java 8 to 17

#295

Post by kaba0 »

weatherlight wrote: post #157
brundolf wrote: post #98

Earlier quoted context omitted.

Counterpoint: it's become a fairly multi-paradigm language at this point, and a multi-paradigm language is exactly what should be the defacto language in curriculums Whether or not Java is the best one for this purpose is up for debate, but I think it's no longer a bad one

Is it though? just because it has lambdas, does that make it functional?

Yes.

Like there is no one definition of most paradigm’s, but what used to be the most FP language, LISPS definitely don’t conform to the more strict FP-definitions like pureness, strong type system, etc. What remains is simply having functions as first class citizens and you can very much save functions into maps or whatever in Java.

Re: New language features since Java 8 to 17

#296

Post by kaba0 »

filoeleven wrote: post #166
grishka wrote: post #107

Earlier quoted context omitted.

Being verbose is a plus. I really really really hate the terseness of Kotlin and how it's basically unreadable without an IDE. Languages should be dumb. Standard libraries should be smart. Not the other way around. The number of syntax constructs that generate standard library calls when compiled should be minimized as much as possible. Edit: one more thing, operator overloading is extremely harmful for readability.

> Languages should be dumb. Standard libraries should be smart. Not the other way around. This is a strong argument for Clojure. The language makes helpful and readable guarantees about data shape, and provides a wealth of functions that operate on its core data structures. Kotlin has a bunch of inferred classes, and Java has a bunch of explicit ones. Clojure recognizes that data does not look like either of those: i…

That is data. Not every problem is fundamentally about data though — the special case you mention may very well be the whole problem domain. Eg. what percent of data does a compositor work with vs state-holding objects with proper structures like WindowLayoutEngine and the like?

Re: New language features since Java 8 to 17

#297

Post by dmitriid »

kaba0 wrote: post #280
dmitriid wrote: post #272

Earlier quoted context omitted.

> instead, we'll have "withers" or "reconstructors When? > On the other hand, C# finds itself needing to add more and more capabilities to this feature, while Java dodged that bullet. Java "dodged it" by never even having to fight. While C#'s "poor choices" are leading to a language with less and less boilerplate with almost each year, in Java we'll have to wait another 10 years before it delivers half of a half of t…

But at the other hand, C# is heading in the direction of C++, where even after n years working with it, it can still surprise you/find yet another way of doing this and the rest. Like, I would prefer not having 10+ initializers from C++ in a language.

But on the other hand you have object initializers directly in the language

In Java you have one of these:

- a hope that someone provided a useful static `.of` method

- a hope that someone provided the 15000 setter methods that you have to tediously invoke one by one

- a hope that someone provided a generator that created a builder that has 15000 setter methods that you have to tediously invoke one by one

Meanwhile in C#:

   new Object {
     x = ...,
     y = ...,
     z = ...
   }
for literally any object (provided properties are public of course).

And don't get me started on array vs list vs collections none of which are compatible with each other. And hundreds of other QoL improvements that are begging to be implemented, and are not.

Re: New language features since Java 8 to 17

#298

Post by pron »

dmitriid wrote: post #271
pron wrote: post #160

Earlier quoted context omitted.

Thank god for that, because those feature are either horrible on their own or superseded by better ones. You're getting a car and complaining for not getting faster horses. The features Java has adopted -- specifically, algebraic data types and pattern-matching -- will lead to better development practices, rather than making it easier to work with inferior ones.

> will lead to better development practices, rather than making it easier to work with inferior ones. C# has these "inferior practices" and is a much better language overall. Why Java doesn't adopt the low and not-so-low hanging fruit from C# is really baffling. Anything from yes, properties, to object initialization shortcuts and a sane IEnumerable/Collection interface that doesn't require stream/toList everywhere.

> C# has these "inferior practices" and is a much better language overall. Why Java doesn't adopt the low and not-so-low hanging fruit from C# is really baffling.

Because Java is doing a lot better than C#, and obviously we feel Java is a much better language overall.

Re: New language features since Java 8 to 17

#299

Post by kaba0 »

BMorearty wrote: post #145
wyager wrote: post #139

Earlier quoted context omitted.

The tradeoff space you’re describing doesn’t reflect reality. Adding more brackets and pointless keywords to a language doesn’t meaningfully improve the programmer experience in any way. There are plenty of terse languages that don’t require an IDE to understand. If anything, Java effectively requires an IDE to use because it’s so verbose. The things that I write in a computer program’s code should correspond as clos…

Excellent counterpoint about Java requiring an IDE because it’s so verbose. In fact when I complain about Java’s verboseness, Java fans tell me “who cares, just use your IDE’s ability to auto-generate code!” But of course that doesn’t help with the _reading_ of verbose code.

Counterpoint counterpoint: an IDE is most definitely not required to write Java, but due to the ecosystem’s size, reliance on IDE and language’s simplicity (that does cause some additional verboseness), Java’s IDEs are top notch and I wager that you actually type less characters for the same codebase in Java than in some less verbose language due to them. So all in all, win-win with more readable code and less typing.

Re: New language features since Java 8 to 17

#300

Post by [deleted] »

p2t2p wrote: post #212

Am I the only one who's seeing "sealed" classes as an unfortunate development? I can't count how many times I had to resolve to using PowerMock and hacking bytecode just to mock something in one of the libraries I use because it's ingenious author "final"-ed the whole API surface of the library (and bits of the implementation usually). Now this gives even greater tool to people who love to lock everything up and thin…

[deleted]
Post reply on HN