James is an open source developer working on Play framework. His passion is making web development simpler, through using the right tools in the right way for the right job. James is a DZone MVB and is not an employee of DZone and has posted 14 posts at DZone. You can read more from them at their website. View Full User Profile

Java 8 Lambdas - The Missing Link to Moving Away from Java

04.07.2013
| 9590 views |
  • submit to reddit
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.

 

Published at DZone with permission of James Roper, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Maurice Naftalin replied on Wed, 2013/04/10 - 9:59am

There's a fundamental misunderstanding in what you write about lambda composition. Compositional methods can easily be added to SAMs if they are defined as default methods (and are therefore concrete).  See, for example, Comparator.thenComparing(). This and other aspects of the new features are explained in the Lambda FAQ (I maintain this).

That has some impact on your main argument, in that the functional features being added aren't broken in the way you suggest. But I do agree with you that Java is not about to become a functional language; the question is whether it will become functional enough to keep the "Java masses" on board. (Though, actually, the really important question is whether the features being added are going to have the overall effect of improving developer productivity and satisfaction, whatever language they end up using.)

Andrew W replied on Wed, 2013/08/14 - 3:33am

I've read a lot of flame about closures, lambdas, and anonymous inner classes.

The best was by a guy named Robert Milner.

It seems that most closures are either anonymous inner classes ( eek -- what a mouthful. let's call them lambdas instead so people don't get them confused with closures that aren't closures.)

Most posters seem to be after something like named code blocks; and most of the confusion seems to be around the relationship between a closure and variables in its (enclosing) scope. The requirement for final variables indicate that the compiler ports the closure and copies of it's required variables to the call site.

Nobody mentions what has to be closest, the C macro: Though many people do implement a basic min/max functor as a 'çlosure', min/max is almost always implemented in C as a macro.

I think the elusive feature people want is like this:


/// define and declare (describe) a fresh lambda
// 
Lambda min = (a, b) -> { return a < b ? a : b; } // let a lambda named min, // locate variables named a and b at a call site, // and produce a result. // the type of the result is the type of the variable found named 'a' // or the type of the variable named 'b' //and here is the lambda used at the call site; File smallerFile( File f1, File f2 ) { let long a = f1.size(); let long b = f2.size; // here, the lambda 'min' will bind to the nearest preceeding variables // named 'a' and 'b' ( that the compiler can verify as being valid LHS // and RHS supporting an '<' operator ). return min; // or even min() } /// yikes! here's some work for !!"Cloud compiler"!! // boolean smallFile( File f1, short b = 2^16 ) { int a = f1.size(); // here, the lambda 'min' will bind to the nearest preceeding variables // named 'a' and 'b' ( that the compiler can verify as being valid LHS // and RHS supporting an '<' operator ). return min != b; // or even min() } /// who knows? // maybe min needs to be declared final. What a handy keyword!

This makes it , kinda, the opposite of a macro. The compiler can 'inject' appropriately named and typed variables into a previously unscoped, named code block.

I'm pretty sure I wouldn't want to debug such a program unless I was absolutely certain my IDE would pop-up a list of all such lambdas described in the program.

Then there's JavaScript, RMI, JavaME, JavaEE, and the reassignment of lambdas names.

"Compiler",  "protect your lambdas!!"

Andrew



Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.