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

181–190 of 358 posts

Re: New language features since Java 8 to 17

#181

Post by karmakaze »

pharmakom wrote: post #102

Glad to see Java improve, but I still would like to see more ML features: - ~Exhaustive pattern matching~ it’s here! - Algebraic data types - Tail call optimisation - Do notation - Operator overload Why not use another language? Well, the name “Java” guarantees buy-in at this point. Maybe it will eventually be a Trojan horse for ML :)

The unfortunate stance on ADTs is that Java doesn't want them generalized. The standard answer is use Records and Sealed classes.

What does this mean? Well with generics we can have two libraries that know about Map and concrete types TypeA and TypeB and can interface type-safely using Map.

What we can't do is have two libraries that know about TypeA and TypeB interface type-safely using a sealed type of TypeA and TypeB. Even without considering libraries, another use we may want to talk about a sealed type of TypeA and TypeC, but of course TypeA can only be in one of the sealed class trees.

The worst part is that Java already has a Union type that's only ever used in multi catch(ExceptionA|ExceptionB e).

Re: New language features since Java 8 to 17

#182

Post by Athas »

brundolf wrote: post #173
Athas wrote: post #164

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

An assortment of specialized languages in different paradigms would probably be better than a single multi-paradigm language. But I was assuming the "CS 101" case, where you're just trying to get a feel for code and probably don't want to be overwhelmed with learning several different languages at once. In this context I think laying a foundation with a single versatile language makes the most sense - a "sample platt…

I suppose it depends on how long that CS 101 course would be. At our department, we used to have an initial half-semester course that taught computational problem solving and programming using Standard ML. It was necessarily based on functional programming, although Standard ML is impure enough that we could also do simple IO. In the next course, they were taught object-oriented design and programming in Java. This has been replaced with a single course that uses F# (a multi-paradigm language) to teach a mixture of functional, imperative, and object-oriented techniques. It is not my impression that the students are left with a very clear conception of these ideas afterwards. Mostly they just seem to loathe F# - more than prior generations loathed Standard ML, even though F# is far more practical and has far better tools.

There can be many reasons for this, but I think people completely new to programming do not have the maturity to juggle multiple paradigms within such a short period of time, and within the same language. Perhaps switching to a materially different language when switching concepts actually helps them, so they don't mix up things too much.

Re: New language features since Java 8 to 17

#183

Post by ohgodplsno »

filoeleven wrote: post #143

The “keep readability in mind” tip exposes more Java/OOP icebergs. var date = LocalDate.parse("2019-08-13"); var dayOfWeek = date.getDayOfWeek(); var dayOfMonth = date.getDayOfMonth(); > The first one is pretty intuitive, the parse method returns a LocalDate object. However, for the next two, you should be a little bit more familiar with the API: dayOfWeek returns a java.time.DayOfWeek, while dayOfMonth simply return…

Because dates are actually complicated, and so is the real world. You may be content in having just an int to display Sun 24-10-2021 to your users, but there are needs to get the actual weekday. From locale differences (US has the start of week on Sunday, most of the world on Monday), to locale differences (Country X nuked 43 days on year Y, your basic algorithm doesn't handle that because it's not working with tz-data, and it's broken now), to locale differences (how do you plan on displaying it? Short form? Translated?), to infinitely more date fuckeries that _have_ to be handled if you want your Date API to be credible.

Re: New language features since Java 8 to 17

#184

Post by filoeleven »

xxs wrote: post #151
filoeleven wrote: post #143

The “keep readability in mind” tip exposes more Java/OOP icebergs. var date = LocalDate.parse("2019-08-13"); var dayOfWeek = date.getDayOfWeek(); var dayOfMonth = date.getDayOfMonth(); > The first one is pretty intuitive, the parse method returns a LocalDate object. However, for the next two, you should be a little bit more familiar with the API: dayOfWeek returns a java.time.DayOfWeek, while dayOfMonth simply return…

>Why does DayOfWeek have a class instead... B/c in most of the world, the 1st day of the week is Monday, unlike the US where it happens to be Sunday. Having it enum is a pretty decent choice.

Sure, someone’s got to make a numbering choice somewhere for the canonical value. Same thing goes for timestamps, and we settled on UTC, so all offsets can be calculated given that.

Once you know that “Java says X is the first day of the week,” you can make your own calculations from it with modulo arithmetic. There is no need for a class here, or for it to build a whole subsystem of locale interpretations. That should be the responsibility of a library. Maybe even the standard library, but it should not mask the core data values in the system by default.

dayOfWeek(n) should be something that you apply to a value, not something that returns a value with no args based on your locale. Or, if it does, the function itself should accept an override locale instead of assuming it from a higher level.

Timestamps are hard and maybe not the best example. It was what’s in the article though, and I’m also pretty salty about them after some recent work stuff.

Re: New language features since Java 8 to 17

#185

Post by oftenwrong »

66fm472tjy7 wrote: post #59
cageface wrote: post #2

Unfortunately it looks like Java is going to evolve enough to take the wind out of the sails of Kotlin and Scala for most dev shops. I guess the positive take is that those improvements might not have happened without the efforts to develop better JVM languages.

I don't think this is going to happen with Brian Goetz as language architect. He refuses to add many features that would address everyday pain points such as: * null safe navigation operator * properties * mutable records * a way to ignore checked exceptions (or at least having the stream API take functional interfaces that can throw exceptions) * adding functional methods like .filter()/.map() directly to collection…

Stream has been given a `toList()` convenience method:

https://docs.oracle.com/en/java/javase/17/docs/api/java.base...()

Re: New language features since Java 8 to 17

#187

Post by mhh__ »

cyberbanjo wrote: post #159
pharmakom wrote: post #102

Glad to see Java improve, but I still would like to see more ML features: - ~Exhaustive pattern matching~ it’s here! - Algebraic data types - Tail call optimisation - Do notation - Operator overload Why not use another language? Well, the name “Java” guarantees buy-in at this point. Maybe it will eventually be a Trojan horse for ML :)

What would do notation add to Java?

Not specifically for Java but I have found myself wanting do-notation in non-functional languages so that I can basically write a very expressive library while also forcing users of that library to go down my road i.e. I hacked around it in the end as I didn't have a do-like abstraction but I had (in-effect, it wasn't quite a DSL) written a DSL that represented certain constructs just fine using operator overloading, but you can't overload control flow. Therefore building the notions I wanted to in code was very painful without some kind of (equivalent notion to) do-notation.

Re: New language features since Java 8 to 17

#188

Post by brundolf »

Athas wrote: post #182
brundolf wrote: post #173

Earlier quoted context omitted.

An assortment of specialized languages in different paradigms would probably be better than a single multi-paradigm language. But I was assuming the "CS 101" case, where you're just trying to get a feel for code and probably don't want to be overwhelmed with learning several different languages at once. In this context I think laying a foundation with a single versatile language makes the most sense - a "sample platt…

I suppose it depends on how long that CS 101 course would be. At our department, we used to have an initial half-semester course that taught computational problem solving and programming using Standard ML. It was necessarily based on functional programming, although Standard ML is impure enough that we could also do simple IO. In the next course, they were taught object-oriented design and programming in Java. This h…

Interesting. I guess my thinking was that "paradigms" are mostly artifacts of a) history, and b) ways of describing ideas which at production scale may lend themselves better or worse to a given problem space (in terms of maintainability, etc), both of which are good to learn eventually, but neither of which matter that much when you're just trying to figure out what code is.

But I guess when you're just trying to figure out what code is, it helps to be able to form very consistent and concrete understanding around basic atoms like "what is a variable?". So if a language has different syntaxes that look similar but don't follow the same rules, that could get bewildering fast. Especially in languages that have sprawled over time and have competing ways of doing the same things.

Maybe the best answer is a language that was designed holistically to be cross-paradigm from the outset? In contrast with a kitchen-sink language that's gathered features over the years

Edit: Another thought; there may be a distinction to be made between "mixed-paradigm" and "cross-paradigm", where one takes the best pieces from multiple paradigms and works them together into a complete whole, while the other just dumps multiple entire paradigms into the same language. Rust for example does a great job of mixing-and-matching without sprawling (not that it would necessarily be a good first language, but for the sake of example)

Re: New language features since Java 8 to 17

#189

Post by grishka »

jmfldn wrote: post #41
jpgvm wrote: post #37

Earlier quoted context omitted.

To be honest I see Kotlin continuing to exist because of it's multi-platform nature and it's focus being on different things to Java. So even if feature wise the 2 equalize (a good thing not a bad thing IMO) stylistic differences will remain. Many of Kotlins syntactic differences are unlikely to make it to Java for instance. I'm ok with this. I use both for different things. Kotlin for most app level development, Kot…

Hmm yes I guess you might be right given Android. It's a shame in a way that Kotlin was invented as Scala could have filled the niche too imho but that ship has sailed. It's too similar to both Java and Scala and doesn't really bring anything new to the table. Is that fair or does it have a great USP other than massive Google backing?

You could soon be able to use modern Java on Android, too. Remember that most of the new syntax features don't need changes to the JVM.

Re: New language features since Java 8 to 17

#190

Post by bradleyjg »

alkonaut wrote: post #186

Does java have a decent story on value types now e.g can I make an ArrayList and trust that it’s one array of longs on the heap and not an array of pointers to Longs? This was what made me ragequit Java 10 years ago.

No. You can’t make an ArrayList at all. You can make an ArrayList and trust the JVM to optimize as it may or you can use c++.
Post reply on HN