<< Understanding the Play Filter API | Home | Advanced routing in Play Framework >>

Java 8 Lambdas - The missing link to moving away from Java

I learnt functional programming, but then I decided I liked imperative programming better so I switched back.
— Nobody, ever

Moving from imperative programming to functional programming is a very common thing to do today. Blog posts on the internet abound with testimonies about it. Everything I've read and every person I've talked to, including myself, has the same story. Once they started functional programming, there was no looking back. They loved it, and in the early days, even the small amount they learnt gave them a thirst to learn more.

To me it seems clear, going from imperative programming to functional programming is a one way street under heavy traffic. It's a diode with a million volts sitting across it. It's a check valve on a mains water pipe. Not only can you not go back, but it comes with an irresistible desire to explore and learn more that pushes you further into functional programming.

Java 8 Lambdas

With Java 8 lambdas on the way, this poses an interesting turning point for one of the largest groups of developers on the planet. Lambdas in themselves don't necessarily equate to functional programming. But they do enable it. And as a developer here starts dabbling in functional programming, a library maintainer there, we'll start to see some new things in Java source code. Methods that previously might have returned null will start returning Optional. Libraries that do IO, for example HTTP client libraries, will start returning CompletableFuture. More and more functional concepts will start creeping into Java interfaces, there will be methods called fold, map, reduce, collect. And so will start the one way street of the Java masses moving from imperative programming to functional programming.

But will Java satisfy their thirst? Looking at the Lambda spec, I suspect not. I see an essence of genius in the Lambda spec, it makes many, many existing libraries instantly usable, with no changes, with Lambdas. The reason for this is that a Lambda is just syntactic sugar for implementing a single-abstract-method (SAM) interface. In Java you'll find SAM's everywhere, from Runnable and Callable in the concurrency package, to ActionListener in Swing, to Function and Supplier in Guava, and the list goes on. All of these libraries are Lambda ready today.

However, this also presents a problem. Functional programming gets interesting when you start composing things. The ability to pass functions around and compose them together gives a lot of power - but the Java 8 Lambdas are not composable. Java 8 does provide a Future SAM, but so does Guava, and many other libraries. To compose these together, you'd need all permutations of composition methods. Two SAM's of the same type aren't even very simple to compose, at least, not in a traditional Java way, since you can't add any methods to the SAM, such as a map or transform method, to do the composing.

So, without the ability to do one of the most basic functional concepts, composing functions, can Java ever become a functional language? Maybe there are some creative ways to solve this that I haven't thought of. And maybe it doesn't need to, I don't think the designers of Java 8 Lambdas had any intention of making Java a functional language, so you can't call this a fault of the Lambda spec. But the problem is the developers, having got a taste for functional programming, as I pointed out earlier, are going to want more, and going to want more fast. Even if Java could become a functional language, I don't think it will keep up with the movement of Java developers to functional programming.

So I'm going to make a prediction. Java 8 Lambdas will be eagerly adopted. So eagerly that Java itself will be left behind, and the majority of Java developers will move on to a language that meets their needs as eager budding new functional programmers.

Which language?

Before I speculate on which language Java developers will move to, let me first just qualify that I am both biased and ignorant. I work for Typesafe, and so am obviously biased towards Scala. And apart from playing with Haskell and ML at university, I have never used any other functional language in anger. So take my words with a grain of salt, and if you disagree, write your own blog post about it.

Scala as a transitionary language

So firstly, I think Scala makes a great transitionary language for imperative programmers to switch to functional programming. Having got a taste for functional programming with Java 8 Lambdas, a Java developer will find themselves very comfortable in Scala. They can still do everything in the same way they used to, they have vars and mutable collections, they have all the standard Java libraries at their finger tips. And of course, they can start deepening their knowledge in functional programming. So Scala provides a smooth transition from imperative programming to functional programming, you can adopt functional programming as quickly or as slowly as you like.

Scala as the destination language

Having transitioned to functional programming, will developers stay at Scala, or will they move on, like they moved on from Java, in search of a more pure language? My opinion here is no. Broadly speaking, I see two camps in the functional programming community. The first camp sees functional programming as a set of laws that must be followed. For this camp, Scala has a lot of things that are not necessary and/or dangerous, and they would probably not see Scala as the end destination.

The second camp sees functional programming as a powerful tool that should be widely exploited, but not a set of laws that must be followed. This is where I stand, and Scala fills the needs of this camp very well. Functional programming has first class support in Scala, but you can always fall back to imperative when it makes sense. I suspect that the majority of the Java community would be inclined to join this camp, otherwise, they would already be shunning Java and writing Haskell.

So I think Java 8 Lambdas are going to be very good for Scala, in that they give Java developers a taste for what Scala will do for them, and thus funnel the masses into Scala development.

Tags :


Avatar: Basu

Re: Java 8 Lambdas - The missing link to moving away from Java

 Great read loved it :) another Scala enthusiast here !!

Re: Java 8 Lambdas - The missing link to moving away from Java

 Or it could be good for Java to get people that could go to scala since it has already those things like lamba.

Re: Java 8 Lambdas - The missing link to moving away from Java

 Hi James,

Allow me to disagree with you :)

Dont get me wrong, FP is really nice and refreshing way to think and solve a given problem and scala is a wondeful language but I bet that once Java 8 comes, the FP bags it carries will be enough for most of java programmers to not move away. It will solve many boilerplate issues, introduce many handy methodes on collection (all the map filter flatmap utilities) and more and overall Java programmer will not feel being left behing when coding simple things while their FP friends laught at them saying how in FP those 20 lines is a one liner.

The issue i see with FP is that it's very simple to get it wrong very quickly and being based on recursion, it's also very simple to forget or not understand the overall complexity(big O notation) of the solution proposed. The other pitfall would also be the syntax that can become very cryptic very quickly as well. One of my mantra when programming is "Clarity over cleverness", FP people seems to always prefer cleverness, leaving code that they themself dont understand right away a week after.

Cedric Beust (Otaku) recently blogged on the FP vs imperative and I somewhat share his opinion: http://beust.com/weblog/2013/01/02/no-silver-bullet-reloaded/

Out of the box, it's true that <span style="font-family: 'Trebuchet MS', 'Lucida Grande', Tahoma, Verdana, Arial, sans-serif; font-size: 13px; line-height: 19px;">Java 8 Lambdas are not composable but if I</span> am not wrong that is exactly what Reactor ( http://blog.springsource.org/2013/05/13/reactor-a-foundation-for-asynchronous-applications-on-the-jvm/ ) or RxJava ( https://github.com/Netflix/RxJava ) are for. Sure having that in the language is handy and better but it's not like it's impossible to compose SAM if it's not in the language to begin with. You might not be able to do exactly everything you could do like in a pure FP language but I am sure that 95% of what most people use can be done.

Avatar: James Roper

Re: Java 8 Lambdas - The missing link to moving away from Java

In my experience, FP (combined with a decent type system) makes it easier to get it right.  If the code doesn't compile, it's often wrong.  Yes, it is simple to not understand the complexity, but FP make no difference to that, it's just as easy to make complexity mistakes in Java as well (for example, prepend to an ArrayList, that's O(n).  What FP does do is favour data structures and idioms for using them that out of the box perform well, while still being immutable and so much easier to reason about.

Syntax can become cryptic in any language, including Java.  A perfect example that I came across just the other day was Doug Lea's implementation of the Java 8 CompletableFuture.  Impossible to read, I doubt he can even read it.  Compare that to the Future/Promise implementations in Scala, far less code, far better variable names, and I can read it with no problems, in spite of the fact that I didn't write it.  Someone that favours cleverness over clarity will do so regardless of what language they are programming in, and so their code will be cryptic.  That's not the fault of the language or the programming paradigm.  So I definitely take issue to you saying "FP people seems to always prefer cleverness", because I certainly don't, and would far rather something readable in 5 lines of code than something cryptic in 1 line of code.

Avatar: Patrick

Re: Java 8 Lambdas - The missing link to moving away from Java

I learnt functional programming, but then I decided I liked imperative programming better so I switched back. (said nobody every)

 

I think the decision to choose FP over an imperitive style is contextual to the problem and any conclusion to choose outside of *some* context kind of reads as an elitetist choice.

Take the scenario where a project is well underway and by and large uses an imperitive style that all the developers are familiar with. To choose FP in this context (even though 1 individual may prefer it) would be a quick trip to failure.

FP must be adopted early on in the project and it (like any technical change) comes with a cost.

IMHO, FP and Imperitive are simply different styles to tackle problems and the pro's and con's of each must be looked at for the problem at hand.

This is a bit of tangent to your Java 8 subject but I just wanted to respond to the first quote :)

Avatar: James Roper

Re: Java 8 Lambdas - The missing link to moving away from Java

 I don't think we're in disagreement here.

The quote wasn't "but then I decided imperative programming was better for every project", it was "but then I decided I liked imperative programming better".  You don't make decisions based soley on what you like and don't like in a project, I still do plenty of imperative programming, just as I still do plenty of Java.  I don't like it, but the best thing for a project isn't just what I do or don't like.

The point of the quote was that I've never encountered anyone who, after learning functional programming, has decided that they prefer imperative programming.  They might switch back to imperative programming, but it won't be because they like it.

Avatar: Ricky Clarkson

Re: Java 8 Lambdas - The missing link to moving away from Java

" <span style="font-family: 'Trebuchet MS', 'Lucida Grande', Tahoma, Verdana, Arial, sans-serif; font-size: 13px; line-height: 19px;">Two SAM's of the same type aren't even very simple to compose, at least, not in a traditional Java way, since you can't add any methods to the SAM, such as a map or transform method, to do the composing."</span>

Sure you can, that's what default methods are for.


Add a comment Send a TrackBack