A Functional Approach to Java: Augmenting Object-Oriented Java Code with Functional Principles

A very warm welcome to you, Ben Weidig, in this forum.

My question is more on the semantics of the language of Java. When I started learning functional programming constructs that were added to Java, I personally felt that it feels forced because obviously, it was designed with the object oriented approach in mind.

So when compared to other pure functional languages, how do you see Java's functional constructs faring against them?

Also, do you think if this limits Java's ability to allow developers to fully realize the potential of achieving the benefits of functional programming?

Thanks & Regards
Dinkar

Hi Dinkar,

thanks for the warm welcome!

Dinkar Chaturvedi wrote:So when compared to other pure functional languages, how do you see Java's functional constructs faring against them?

That's a tricky question... if I say Java's not good for FP, no one will buy my book

Jokes aside, Java's functional support can feel quite constrained or forced compared to a "pure" functional language, but I think that's to be expected in a multi-paradigm language without such support from the ground up.
But for me, that isn't the issue or the eventual deciding factor to use it.

As I see it, the Java team did a fantastic job integrating the possibility of functional programming in a way that works without breaking the language and is quite close to how Java devs would expect it..
Naturally, this is a trade-off and affects how "pure" the functional support or how good the constructs are compared to other languages that don't focus on compatibility, or don't need to integrate it 12 years after the language's inception.

For example, backing each lambda with a concrete type as a functional interface makes them first-class citizens without breaking Java, as there are no dynamic types.
Pre-Java 8 interfaces even become usable for lambdas automagically if the comply with the "single-abstract method" requirement of functional interfaces.
However, enforcing concrete types can create incompatibility between identical lambdas that are represented by different types.
I talk about this in the book, and usually, type inference or bridging the gap with a method reference is enough to make it work.
From a pure FP point of view, that might feel subpar, and it is, but from a Java devs view, you still have access to many of the benefits of FP without needing to go fully functional.

Also, do you think if this limits Java's ability to allow developers to fully realize the potential of achieving the benefits of functional programming?

If a developer only checks out a single language trying to realize the potential of a paradigm's ability, then I'd say yes.
But I wouldn't recommend Java as the language to learn/use if you want to be exposed to the full potential of FP.
Just as you wouldn't start/use F# for being exposed to the full potential of OOP, either.
Sure, you can use either language for both paradigms, but software development is about choosing the right tools for the job.

For me, Java's functional support is a great way to get your feet wet and see the tip of the FP iceberg.
That's why I called my book "A Functional Approach to Java" and not "Functional Programming with Java".
Being able to introduce FP into your Java code base gradually is the real benefit of Java's functional support, in my opinion.

Ben Weidig wrote:
need to integrate it 12 years after the language's inception.

This made me curious about the timeline...

Java 1.0 came out in early 1996

Java 8 added lambdas and came out in the spring of 2014

So that's about 18 years -- which makes what the language's designers did even more amazing, in my opinion. Java is 27 years old and has had 20 major releases so far (with another due in three months) and yet it has retained backward compatibility in nearly all cases, while still changing in some fairly radical ways.

Language design and stewardship are hard! Brian Goetz (who was the spec lead for lambda expressions) gave a great talk about this, the year Java 8 was released, at Clojure/conj (of all places!). Definitely worth watching: https://www.youtube.com/watch?v=2y5Pv4yN0b0

Sean Corfield wrote:So that's about 18 years

Looks like it's time for the weekend when I can't do such simple math anymore


Exactly, the language design, good stewardship, and preservation of backward compatibility to the vast ecosystem IS the main selling point for Java IMHO.
If that means there are trade-offs in areas of how well certain features can be integrated, I'm ok with that.
There's still a lot to gain from such features.

Looking at my other most-used language, Swift, I see quite a different approach to a programming language.
It's an interestingly designed language with many features done right.
But the price was the lack of ABI stability before version 5 and multiple changes to the syntax over the years.

So each yearly iOS release brought a new Swift version that broke your code and dependencies.
Combined with the fact that Apple forces you to recompile and re-upload the app every other year, that's quite a nuisance!

Ben Weidig wrote:. . . time for the weekend . . .

Hahahahah!
You have put no end of effort into answering the many questions you have been asked: thank you

It was my pleasure!

Getting critical questions and being confronted with different views and backgrounds is always a good way to re-evaluate and re-adjust your own point of view.

Thanks to all of you for the interesting and sometimes not so easy to answer questions!

Thank you Ben Weidig for the insightful responses. This was helpful.

Also thanks to the members who ensured that I took away accurate information about the quick lesson on Java's history.

Thanks again!

Regards,
Dinkar