Hacker News Reader

Comment by dack | Hacker News Reader

This resonates - I've thought about certain technique and language couplings as "impedance mismatches", where the technique itself is fine and good, but the language makes it a horrible experience that's not worth it.

The example that I've run into most is trying to write functional immutable code in Java. I have just never gotten it to work well - of course there are libraries that have weird workarounds (that aren't compatible with standard data types or libraries), or tons of boilerplate you could write, but ultimately Java just fights you the whole way. It's not really worth going down that path imo, and better to switch to something like kotlin or scala if you can.

View on HN

If you have to interact with classes that do some reflection-based magic and you need the getter setter convention, yeah it is hard. But with records I really don’t feel that it would be bad. It didn’t become a haskell overnight, but one can write FP in Java reasonably well.

In the C -> C++ -> Java -> Scala progression Java was a gigantic golang-style detour from a multi paradigm language. STL had so much power and a lot of it can be attributed to quasi-FP abstractions. The first few posts in Bartosz Milewski's blog showed the same examples in both C++ and Haskell.

What surprises me is that even among those lucky to work on a powerful platform such as the JVM or .NET it's more typical to stick to a single language. In my mind it'd be more natural to write Java/Kotlin/C# when you want imperative abstractions and Scala/F# when you are in mood for FP. The same platform/libraries, the same IDE/toolchain, only the syntax/abstractions differ.

But we know that Scala and F# adoption is nowhere near what some of us would hope for. We also know that the ecosystem fragments immediately and Scala projects don't share [m]any libraries with Java ones for example. So mixing the two languages in one system is mostly about wrapping some legacy code.

The "worse is better" essay touched upon some deep truth.

Try Kotlin, they basically just fixed that, keeping the rest of Java as it is.

Java 17 is getting pretty good about this. Records in particular are great.

@Value and @Builder from Lombok get you halfway to Scala case classes. Just because Java requires a bunch of noise doesn’t mean your staff has to reread it.

Having arguments against Java deflected with "oh but annotation processors" is so annoying. Just because you can somewhat patch the holes doesn't make it a weakness of the language. Same arguments are used for C ("just use static analysis") or untyped languages ("just add a bunch of unit tests")

In my current project we use Error Prone, Checkstyle, Immutables, JSR305, NullAway and a couple of other things. It makes the language tolerable, but it's a massive waste that each setup needs to introduce and tune those, and often inexperience or lack of knowledge will mean they're never introduced, if only because after a while they become painful to introduce.

Better languages exists, some are even JVM, which just do this stuff properly.

Reply on news.ycombinator.com