Venkat Subramaniam

Thank you so much for having me here, Jeanne and the organizers.

Special thanks to everyone for your questions and comments. Best wishes for all things ahead.

Congratulations to the winners, Piet, Michał, Don, and Majid.

Cheers.

I agree, Burk, with experience and willingness to shift between the paradigms as needed helps.

Hi Don,

Programmers can write good code or bad code in any language and in any paradigm. Lambdas are no exception. But, as a team we can do quite a bit to make the code easier to understand and maintainable.

The chapter in the book titled "Functional Programming Idioms" speaks directly to this. Please see the table of contents at https://pragprog.com/titles/vsjava2e/functional-programming-in-java-second-edition

A few situations:

The code has a lot of unavoidable side-effects that can't really be pushed to outside the functional pipelines.
The code would turn complex due to excessive exception handling and loose clarity or cohesiveness.

It is a good quality to be willing to evaluate, by way of prototyping, if imperative or functional style is a better choice for a particular problem on hand.
I often say that we're not in a competition where we are required to program in a particular style. We should be willing to pick what makes sense for a given situation.

Thank you Adrian and best wishes for all things ahead.

Hi German,

I do discuss the performance implication of using parallel stream and why it is important to be cautious about the using parallel and also number of threads from the performance point of view. The book does not focus on performance tuning, however.

Lambdas are not implemented as objects on the JVM and do not have the same GC demands as objects or instances of anonymous inner classes do. This is one of the remarkable solutions in Java, the user of invokevirtual to implement calls to lambda expressions. I discuss this in the book to ease the general concerns over memory footprint and GC.

The one that my clients are using for development, I love them all.

Hi Burk,

Refactoring is about changing how the code does its work without changing what it does, that is without changing its external behavior. In that sense, we have to be able to define the boundary of what we consider internal vs. external.

For example, if we consider an imperative style code where we have a local variable within the function that is mutated within a loop. As far as the loop, it has a side effect on what's outside of the loop. If that variable were a field instead of local variable, that side-effects is much worse.

In the refactoring chapter the examples discussed deal with the first case, where the changes are local. I do not focus on the larger side-effect of fields. Such side-effects will require further refactoring to remove the side-effects to fields before applying the functional techniques.

The original concept of OO was more about behavior than state. Practices over the years have deviated from the original principles.

When mixing OO and FP, we want to avoid mutating state while we're in the middle of the functional pipeline. Also, we can use functional style within the methods. For example (not not limited to), instead of iterating in a method using the imperative style we could iterate using the functional style.

Instead of clashing, these two paradigms can collaborate well, however, we do have to be disciplined when dealing with state.

Hi Don,

If we create a function we can decide when to call it. A lambda expression is a function, albeit anonymous. Thus, we can defer their evaluation.

Lazy or deferred evaluation is critical for functional programming as it has direct impact on efficiency. Passing around functions to functions, which is a fundamental idea in FP, helps to defer evaluations naturally.

Hope that helps.

Hi Majid, the chapter "Designing with Lambda Expressions" covers this topic of your interest.

Hi Majid,

The book does not touch on Reactive Programming since I want to stay focused on the topic of the book. The book does cover the pros and cons of parallel streams.

Thank you.

Hi @Burk,

In my experience, having worked with a number of languages that provide either strict FP or hybrid FP, I have found it to be a pleasant experience to drive the design of code using tests for functional style of coding. I have found two specific benefits:

1. The purity of functions turns into fewer set up that may otherwise be necessary.
2. I often use lambdas as lightweight stubs/mocks instead of creating more complex stubs or mocks.

Overall, I have had a wonderful experience mixing TDD and FP. Neither was easy, of course, in the beginning when I was new to them.

Hi Carlos,

I often like to give the analogy of building a wall. We may use clay or cement to "glue" the brinks together. I often think of the imperative style of a way to glue the bricks (objects) and functional style as yet another way to glue them together. You may, for example, iterate over a collection of objects using imperative style or the functional style. Much like how imperative style goes beyond iteration, functional style does as well. The benefit is reduced complexity of code.