Is functional programming with Java worth it?

Hello Ben Weidig,

Welcome to the ranch…

Correct me if I am wrong but, with the addition of lambda expressions, a developer can pursue a functional style with Java.
However, I have heard from the “functional programming crowd” that functional programming in Java is missing some features that make the transition barely worth it.

Do you think this criticism has any basis in fact?

Thank you for your time.

Sincerely,
Anthony

Anthony Esposito wrote:... I have heard from the “functional programming crowd” that functional programming in Java is missing some features that make the transition barely worth it.

Did they provide any details as to what features were missing?

Hi Anthony!

That's a quite common question about Java and FP, with a complex answer.

tl;dr:
Yes, I think you can criticize Java for not being "fully functional" and lacking features compared to other languages, but that's not the point of FP in Java, at least as I see it.

You wouldn't transition to Java only for its FP capabilities.
There are other languages that are "more functional", even on the JVM.
Scala is a great example of FP+OO in a single language, and Clojure is more of a "FP to the max" variant.
But that doesn't mean that a functional approach in Java is without merits.


Time for the longer answer...

Looking completely isolated at FP, comparing what's possible in languages other than Java, you can clearly see that Java isn't the best match.
Java might be a multi-paradigm language with a lot of functional and functional-akin additions, but it still isn't a "fully" functional language.
That's why I called the book "A Functional Approach to Java" instead of "Functional Programming with Java" or something similar.

For a greenfield project, we might start with the "perfect" language for a problem, but how often is that really the case?
Adding another language to an existing code base is possible, but we must consider the ramifications.
If you're the only developer on something, the decision might be up to you, but working in a team affects all of them.
Even though I would love to integrate Scala, Clojure, or Kotlin into my company's projects, my colleagues would have to deal with it, too.
Instead of forcing an FP language, we decided to stick with Java and do "a more functional approach" to certain topics instead.

Java's strengths are its general robustness, backward compatibility to a level that even hinders certain advancements, and a vast ecosystem.
Especially its backward compatibility means we have to deal with certain design decisions, even if they don't fit well or even hinder straightforward functional code.

Features like static types, lack of dynamic tuples, checked exceptions, nullability, or lacking tail-call optimization make Java "harder" than other languages for functional code and certain use-cases.
But which language is perfect for every use-case?
I think every language is missing some features, depending on how you look at it.

Most of the topics I discuss in the book are great for any paradigm.
Is it really important that Streams are declarative pipelines of higher-order functions?
Or that immutability, a cornerstone of functional programming, solves a lot of state-handling issues?

It's about opening up your mind to new possibilities, like approaching your problems with a functional mindset, even if the solution won't be as functional as it might be with another language.

As Brian Goetz, the Java Language Architect at Oracle, said in one of his talks:

Don’t be a functional programmer.
Don’t be an object-oriented programmer.
Be a better programmer.

Anthony Esposito wrote:. . . “functional programming crowd” . . .

However half‑baked an idea is, there will always be somebody who will espouse and publicise it. That is why we ask you to say where that comes from. Rememberr that however barmy an idea is, there will be somebody who will write it on theirr website.

Another thing to remember is that learning a new paradigm will make you a better programmer (as Brian Goetz is quoted as saying) whether you use that paradigm directly or not.

Absolutely!
It doesn't have to be another paradigm, either.
I think we can benefit from learning about any language when we try to understand why a language is designed the way it is.

In Java, for example, it's easy not to think much about memory management unless there's an issue.
Working with Rust gave me a better understanding of lifetimes and their importance (and a lot of frustration with the borrow checker )
When I now work with Java, I think more about the impact a data structure has, how long it might live, and how I avoid creating too much unnecessary overhead.

Or working with Swift made me appreciate guard clauses that force an early return.
Even though there's no keyword for that in Java, I try to put essential checks first and return early if necessary instead of an inverted condition and nesting the code further.
The code might have more return points, but I prefer the reduced nesting and more readable code.

Ben Weidig wrote:. . . guard clauses

Round here, we have a reversible language which supports explicit guards with a -> operator. A failing guard triggers reversal of the program. Guards also appear in language semantics.

. . . there's no keyword for that in Java, I try to put essential checks first and return early if necessary . . .

Rather than throwing an exception?

Campbell Ritchie wrote:Round here, we have a reversible language which supports explicit guards with a -> operator. A failing guard triggers reversal of the program. Guards also appear in language semantics.

That sounds interesting. May I ask which language?

Rather than throwing an exception?

I meant returning early in a more general sense.
Depending on the context, an Exception is an appropriate "early return", but I prefer designing my APIs with fewer Exceptions these days, as they are not much fun to use in Java lambdas.

There are two, one being called RVM Forth. Unfortunately I can't at present run the other language.
Agree about exceptions and λs. The conventional story about checked exceptions was convincing, and they woked as they were supposed to. Then λs and Streams appeared, and they don't play well with checked exceptions, so they ended up with a little bit of a cheat: this

RVM Forth only runs on a Unix‑like box and requires a certain 32‑bit C library. My own language (RuthR) requires RVM Forth to run. RVM stands for reversible virtual machine.

Campbell Ritchie wrote:There are two, one being called RVM Forth

Reversible computing sounds quite interesting, thanks!
I've put a few papers on my reading list.

so they ended up with a little bit of a cheat: this

Unchecking an Exception is absolutely a cheat!
And it was "abused" even before lambdas entered the scene.
With lambas, however, it's sometimes a necessary evil to regain some form of sanity, even though it always feels weird to do so.

You're right, the conventional story for checked Exceptions is a convincing one, and if used "correctly", they can be an incredible tool.
Sadly, I think they're often a misunderstood or misused/overused feature and can be more of a nuisance and obstacle to overcome.

Hopefully, someday we get a language-level tool to deal with them, as approaches like Kotlin's "let's treat them all as unchecked" don't sit well with me, either.

Maybe something like what Swift does with the keywords try, try?, and try! in front of a throwing method call to indicate either:

try: this call requires a do-catch-block

try?: no do-catch, but the method's return value is wrapped into an Optional, which is empty in the case of an Exception

try!: trust me, I'm an engineer... meaning no do-catch, but the method will blow up in the case of an Exception, as the call is wrapped in a runtime assertion to not throw an error.

This way, the catch-or-specify requirement would still be there, and method signatures confer all the information you need to not be surprised by an Exception, but the compiler can force you to make a conscious decision on how to handle things.
Even if you just want to ignore an Exception, you have to say so yourself.

Ben Weidig wrote:. . . Reversible computing sounds quite interesting, thanks! . . .

That's a pleasure

Tangent warning.
We used “weakly reversible” programming, which means we can only execute code backwards if it has already been executed forwards. That has the advantage that the forward execution can cope with non‑determinism. Most people follow the lead of the Janus language which is strongly reversible; it can execute in reverse if it is given the end result. But (I think) it cannot usually cope with non‑determinism in either direction.