Java SE 8 for The Really Impatient: Lambda Expressions

[Kondwani Chipeta]

Hello Cay,

Congratulations on the book.

My question is mainly focused on Lambda expressions. Having read a number of articles here and there, I am intrigued by what lambda expressions will bring to the Java ecosystem.
Having first learned Java on version 1.6, I am curious, do you believe that Lambda expressions will make it more efficient for us Java developers to write code and deploy software?
Is the learning curve for lambda expressions steep or is it something you can easily pick up?

Regards,

Kondwani.

[Joe San]

Lambda expressions are just another language feature. I don't know how it might help you to deploy better software, but definitely you will write code that is much elegant and readable using lambda expressions. Well lambda expressions are just higher order functions and the moment you start abstracting behavior out into higher order functions, your code becomes beautiful. Writing efficient code entirely depends on you and it is not given that with lambda expressions you always guarantee efficient code. I can write a lambda expression and mess my whole application up.

Now for your other question - Is the learning curve for lambda expressions steep or is it something you can easily pick up?

How long did it take for you to know about passing and returning objects to and from methods respectively? Understanding lambda expressions should also take you the same time.

[Cay Horstmann]

Most people don't seem to have trouble with lambda expressions, once they get past the "lambda" term :-)

It's just a function without a name. A block of code that you pass somewhere to get executed later.

It's a little more complex than that because the block of code can refer to variables in the enclosing scope, but as long as you don't worry how that is implemented, it's a non-issue.

In JavaScript, people use lambdas all the time. They just call them anonymous functions, and everyone stays calm.

Cheers,

Cay

[Kondwani Chipeta]

How long did it take for you to know about passing and returning objects to and from methods respectively?

Not long Joe, so if it's the same with lambda expressions then that's great.

Thanks for the reply Cay.


Regards,

Kondwani

[Bell Katapa]

Hello Joe,

I have generally lagged behind with the core Java language since the release of version 6.0 (concentrating mainly on Java EE), picking up only diamond operators and direct usage of Strings in switched statements from Java 7. I am yet to pick up a Java 8 material and try out new stuff. I have had exposure to JavaScript anonymous functions though. Would i be correct to assume that the concept of lambda expressions is similar in complexity or readability to that of Java-based anonymous inner classes?

Am just curious.

[daniele licitra]

Cay Horstmann wrote:It's just a function without a name.

So, Java8 don't introduce something like functional programming?

In languages like Scheme or Haskell, you can define a function that get a function like input and return also a function.
for example, in pseudo code
sum(x, y) can get in input two function, two string, two number and return the function x+y

Is this implemented?

[Mike. J. Thompson]

daniele licitra wrote:

Cay Horstmann wrote:It's just a function without a name.

So, Java8 don't introduce something like functional programming?

In languages like Scheme or Haskell, you can define a function that get a function like input and return also a function.
for example, in pseudo code
sum(x, y) can get in input two function, two string, two number and return the function x+y

Is this implemented?

Lambda expressions do create functions in the sense that nothing in the lambda expression is evaluated until it is called (lazy evaluation). They encapsulate blocks of code that can be passed around rather than data values that are passed around, and so turn code into data which I guess it the essence of functional programming.

Syntactically I don't think you can call them functions thought because they produce objects with methods, and you need to call the method by name. For example if you have the call:

myMethod((x,y) -> x + y);

then the definition of myMethod might look like:

public <T> T myMethod(Function<T, T> theFunction)
{
    return theFunction.apply(1, 2);
}

If you could truly call the object that the lambda expression created a function then you would use it something like:

public <T> T myMethod(Function<T, T> theFunction)
{
    return theFunction(1,2);
}

That's more a matter of syntax though, and I would say that the lambda expression behaves very much like a function. It certainly moves Java a lot closer to Haskel than it used to be, but you could ultimately still call myMethod in the code above using an anonymous interface as we would have done in previous versions and it's possible to use Java while making absolutely no use of any of the new functional aspects.

[Rob Spoor]

Mike. J. Thompson wrote:

myMethod((x,y) -> x + y);

You mean myMethod(Integer::sum), right? Integer, Long, Float and Double all have sum, min and max methods added just so you can use them in lambdas.

[Mike. J. Thompson]

Rob Spoor wrote:

Mike. J. Thompson wrote:

myMethod((x,y) -> x + y);

You mean myMethod(Integer::sum), right? Integer, Long, Float and Double all have sum, min and max methods added just so you can use them in lambdas.

Well indeed, there's always more than one way to skin a cat. I just felt that method references (ironically) don't look much like functions. Since we were talking specifically about functional programming I wanted to use something that looked like a mathematical function.

[daniele licitra]

Mike. J. Thompson wrote: lazy evaluation

Thank you, now is more clear. Sometimes two words are better than one thousand words