New language features since Java 8 to 17 • Hacker News Board

Re: New language features since Java 8 to 17

#211

Post by pron » Sun, Oct 24, 2021, 11:06 PM UTC

xpressvideoz wrote: post #204

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.

I can understand the hate behind null-safe operators, but why properties? Why is bad to have an ability to "upgrade" a member variable into a property, without breaking any existing contracts? I really hate that I need to resort to using setters and getters in Java because those are bad for searchability.

Properties are probably the worst feature on that list, and no experienced language designer would add them to Java. They make it easier to work with setters, while the goal is to reduce their usage altogether! Records achieve that much better. Unencapsulated component access is standardised on classes with good contracts (construction and deconstruction are duals for records) and will work well with patterns, all while avoiding unnecessary mutation for such classes (instead, we'll have "withers" or "reconstructors": https://github.com/openjdk/amber-docs/blob/master/eg-drafts/...).

So we're killing two birds with one stone: making it easier to work with "simple data" while also reducing reliance on getters and setters. On the other hand, C# finds itself needing to add more and more capabilities to this feature, while Java dodged that bullet.

Re: New language features since Java 8 to 17

#212

Post by p2t2p » Sun, Oct 24, 2021, 11:13 PM UTC

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 think that they know better than me what I need.

Re: New language features since Java 8 to 17

#213

Post by abraxas » Sun, Oct 24, 2021, 11:22 PM UTC

Twisol wrote: post #197

hota_mazi wrote: post #122

Earlier quoted context omitted.

Anyone who values static typing will never be in awe of Clojure. Or any dynamically typed language, for that matter. And Java developers care a lot about static typing.

> And Java developers care a lot about static typing. With the amount of reflection and annotation-based magic I've seen in the ecosystem, I'm not sure I actually believe this? Maybe it's just lack of exposure, but most of the Java devs I've met seem very happy to undercut the type system whenever it's convenient.

Java annotations are type safe. And dynamic types is precisely what turns me off of Clojure

Re: New language features since Java 8 to 17

#214

Post by abraxas » Sun, Oct 24, 2021, 11:25 PM UTC

dunefox wrote: post #175

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…

> 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? Var and type inference are neither antithetical to static typing nor do they make a language dynamically typed. They're antithetical to the verboseness of Java.

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.

Re: New language features since Java 8 to 17

#215

Post by titzer » Sun, Oct 24, 2021, 11:27 PM UTC

I used to really love Java, it was my second "real" programming language after C/C++, and GC, type safety, and object orientation really changed the way I thought. I also learned almost all I knew about high-performance VMs (up to 2013) in the context of JVMs.

But these days it seems like Java is engaged in one long apology for the "everything is an object" mindset it started out with. It both took it too far and not far enough. Erased generics were the start of the problem. Parametric types! You were the chosen one! You were supposed to unify the primitive types and the object types! And never adding syntax for function types, just single-method interfaces...just ugly and clunky IMHO.

C# did generics right. Well, almost. "void" isn't a real type, so you can't be generic over it.

It is really important in language design that generics can range over any type. It allows the full combinatorial space. I worked really hard to make the Virgil compiler support arbitrary combinations of tuples, arrays, function types, and all of those work together seemlessly in the polymorphic type system. Everything else is a unfortunate shortcut, IMHO.

Re: New language features since Java 8 to 17

#216

Post by tialaramex » Sun, Oct 24, 2021, 11:32 PM UTC

dukeyukey wrote: post #110

weatherlight wrote: post #95

Java sucks, and should stop being taught as the defacto language in computer science curriculums. It's extremely busy and verbose. There are better OO languages out there, if the point is to teach OO. (I'm ready for this post to get downvoted into oblivion)

I agree with everything here except the "should stop being taught as the defacto language in computer science curriculums". Realitically, a CS curriculum needs to at least vaguely prep a student for life in the industry, and Java is not only massively popular, but is also a great way of showing how OO is used in practice i.e. kinda badly. No point teaching everyone about beautifully architected Smalltalk programs jus…

> Realitically, a CS curriculum needs to at least vaguely prep a student for life in the industry

It's sad that people see the primary teaching language of a CS course as somehow important for this purpose. Sad that students see it this way, sad that their parents see it this way and particularly sad that would-be employers often see it this way too.

Particularly languages favoured by industry are unlikely to offer CS students anything to be passionate about. Yes, it's true that lots more of them will get jobs maintaining code written in a then-current Java in 2005 than will be writing green field Haskell. But if we just wanted code monkeys a three (or four) year degree is massive overkill.

Re: New language features since Java 8 to 17

#217

Post by erik_seaberg » Sun, Oct 24, 2021, 11:32 PM UTC

jpgvm wrote: post #90

jmfldn wrote: post #61

Earlier quoted context omitted.

I hear this a lot about Scala, and I am a Scala dev so maybe I'm biased, but I don't get the difficulty angle particularly. I'm in no way exceptional as a programmer or IQ-wise but I picked up Scala easily as part of my first job. The difficulty thing doesn't compute to me but it could just be that I'm well-suited to the language. It works beautifully as a better Java if that's how you wish to use it. Granted, it mig…

It's difficult because the language is gigantic compared to Java, it has all the OOP bits Java has (and Scala needs in order to be relevant) then a whole bunch of FP stuff on top. This is a lot for newer programmers and while they might be able to do "hello world" equally quickly I do feel like they soon hit a wall of "I don't understand why this works" when looking at idiomatic Scala. It can be used as a better Java…

Every worthwhile language brings important choices that require discipline. If there’s only one way to do anything, your experts’ code will be just as bad as your beginners’.

Re: New language features since Java 8 to 17

#218

Post by xxs » Sun, Oct 24, 2021, 11:32 PM UTC

jcelerier wrote: post #198

filoeleven wrote: post #184

Earlier quoted context omitted.

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

> Once you know that “Java says X is the first day of the week,” The basic assumption when designing anything is that you can never rely on assuming that other humans "will" know.

A funny part is that java has java.util.Calendar that has setFirstDayOfWeek(int), the default depends on the locale used to create the Calendar. It's considered a bad design overall, esp with SUNDAY const being 1. For most of the world that (sun=1) made absolutely no sense at all and assumed one of those weird things like jokes about IQ and room temperature.

Re: New language features since Java 8 to 17

#219

Post by kjeetgill » Sun, Oct 24, 2021, 11:40 PM UTC

bradleyjg wrote: post #190

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

You can mostly trust the JVM to not optimize this the way you'd want for primitives. ValueTypes are int he works though, and using a supplementary library for primitive specialization like Trove or fastutil have become the norm for now. Not ideal, but tolerable!

Re: New language features since Java 8 to 17

#220

Post by Twisol » Sun, Oct 24, 2021, 11:40 PM UTC

abraxas wrote: post #213

Twisol wrote: post #197

Earlier quoted context omitted.

> And Java developers care a lot about static typing. With the amount of reflection and annotation-based magic I've seen in the ecosystem, I'm not sure I actually believe this? Maybe it's just lack of exposure, but most of the Java devs I've met seem very happy to undercut the type system whenever it's convenient.

Java annotations are type safe. And dynamic types is precisely what turns me off of Clojure

Java annotations aren't executable on their own, so they're trivially type safe. The systems that do things depending on those annotations are typically reflection-based, which does an end-run around the static type system and usually requires a lot of casts.

I like static typing myself, but having experienced languages with better type systems, Java's feels like a straitjacket. It's unsurprising that so much of the ecosystem (such as in Spring) leverages reflection and dynamic classloading shenanigans.

Props to Dagger for doing compile-time dependency injection well, though.