JavaOne Preview: Java Functional Programming in an Interview with GridGain CEO Nikita Ivanov
This month GridGain CEO Nikita Ivanov will be speaking about functional programming at JavaOne in San Francisco. With its 3.0 release, GridGain added a more functional feel to its product by reworking the APIs. InfoQ contacted Mr. Ivanov to get the deeper story about his company's experiences with functional programming.
Mr. Ivanov started with being inspired a couple of years ago when creating a roadmap for their 3.0 release. They started planning with "a growing sense we have to provide a much more simplified usage model along the lines of a DSL." With Java they felt they had "hit the wall how much simpler it can get" and so tried creating Scala DSL. When they were done, they were "startled" when they placed the same code side-by-side.
On the left side, we had the Scala code which was very functional, very concise, very pragmatic and on the right we had the Java code and it looked bloated and it looked basically three to five times longer....we saw first hand how 45-50 lines in Java became two lines in Scala without any syntatic trickery.
Inspired by Scala, GridGain went about reworking the GridGain APIs with the goal of making them have as close a native functional feel as they could while still remaining pure Java. GridGain discovered that they couldn't just port code from Scala because Java was missing some fundamental functional constructs:
You really have to create the entire new framework....you start with your closures and predicates...it starts with a very comprehensive list comprehension library: it's currying and distributed currying; it's recursions and distributed recursions; and on and on and on.
Consequently, GridGain built the missing functional constructs into their product. Mr. Ivanov emphasized that their API is not another language, it's still just Java. He described the result as
...pretty much as close as you can get technically to a post-functional feel. It's not because we're smart or anything. We were able to look at existing frameworks that were developed in the last two or three years and really took out the best from them and integrated them natively so all these constructs don't feel like an afterthought.
When asked what the prefect functional use case was, Mr. Ivanov answered that here is no pure functional or pure object oriented use case. He added that "post-functional" languages like Scala illustrate best the need for both.
Object orientation excels at the higher level where we reason or think about our classes with inheritance, encapsulation and packages where these big items get glued together...No matter what Clojure or Haskell will tell you, it's pretty limited in a way how a pure functional language can think about packages, classes, inheritance, and things of that nature.
In contrast, he went on to describe functional orientation excelling
...when you get to the level of code, of basically implementing your algorithms...your methods. In Java the object orientation becomes basically a drag. It's too heavy. These are not my ideas, it's prevailing wisdom right now.
We asked Mr. Ivanov about the future of Java and functional programming and he closed with:
Java 7 was pushed to November 2012, that's almost three years away again. Java is definitely going to be relevant in 2 or 3 or 5 or 10 years from now but it's kind of worrisome that Java itself as a language will not get any help from its own syntax....If you are not married to Java there's nothing else like Scala today. But for many other organizations Scala is not an answer for many reasons...for years to come Java will be the predominant language in the enterprise. There's an abundance of developers and an abundance of software.
Those attending JavaOne who want to hear more from Nikita Ivanov can catch his presentation on Thursday the 23rd at 2pm.
Functional Programmers have to stick together
As a technology adopter, you are under no obligation to evaluate every other option under the Oracle. But if you did have a few minutes to evaluate Clojure, you would find that Clojure is not purely functional, and that (2) Clojure supports interfaces, classes, and packages in ways that are simpler and more powerful than their Java counterparts, while still being usable from Java.
Best of luck at JavaOne, and I hope your talk will convince other folks to try functional programming on JVM.
Tom Gilb & Kai Gilb Jan 26, 2015