What do experts say to the investment in absorption time of the mechanics of lambdas in Java 8 ? Is it knowledge worth acquiring? And are there any noticeable performance improvements over the previous implementation model, that would make the efforts worthwhile anyway?
LVL 17
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

We'll see what the real benefits are long term - but the main benefits should mostly be around better support for parallel processing.

If you move some code over to lambdas (and streams really) then you can parallelize it much more easily, because it avoids storing data in local state.

Is that noticeable?  Well, of course that depends on the problem you're trying to solve.  But machines with many many cores are increasingly common.


Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Functional Programming isn't a performance bust feature, it is a readability feature. There is nothing that you may do with Java Functional Programming that you can't do with Java, but you also can say that there is nothing that you may do with Java that you can't do with Assembly. If you imagine the effort that was to build this feature in Java, you may imagine that there is big value expected for the Developers.

Java is just starting with the Functional Programming. I'm a Scala developer and when you take the code to that level, you leave in a better world :)
krakatoaAuthor Commented:
Nice comments, thanks.

This may be a bit jejune, but is there no role that the compiler could have played, optimisationally, in all this , rather than introduce a new limb of the API?

(BTW, long time no see oleber) ;)
OWASP: Threats Fundamentals

Learn the top ten threats that are present in modern web-application development and how to protect your business from them.

I never been a Java developer, so I did it for the fun.

When do EE open a Scala section?
compiler could have played
Compiler level solutions to parallelism (which IMO is really the big win for functional programming) have been worked on for some time.  It's a very hard problem - the closest "solutions" are probably software transactional memory ( - where the compiler resolves all concurrency problems for you and rolls back bad outcomes (due to conflicts).

It's cool stuff, but just like with the functional programming the question is what do you lose (in performance typically) when you move to these designs.  So far compiler level solutions are still "too slow".  Functional programming has been around forever (LISP, PROLOG, ML etc.) but it's also always died a death in the real world because pure functional languages don't allow any modifiable state.  That's great in theory, but ugly in practice (copying a huge data structure each time is just too slow - although languages like Clojure try to solve that by making data structure look immutable while under the covers they actually modify them).

The interesting thing about Java's (or Scala's) approach to functional is that they are giving you the ability to go functional where you wish, so you get the benefits of parallelism and clarity where it makes sense, but you can still be imperative and assign values to a big hashmap, when that also makes sense.

Will it work?  We'll have to wait and see...

krakatoaAuthor Commented:
Great Doug. Well that will give me more than enough to think about and try to understand for quite some time! ;)
On the performance side, if performance would be so essential we should all be developing in Assembly or C. In reality they are as fast then other like Perl, Ruby or Python. The problem of the Functional Languages are the developers, the University teaches developers to develop in Imperative or OO languages and after the developer tries to do the some with pure functional or logic programming languages. The mistake are obvious from there.

Note: PROLOG isn't Functional Programming.
he problem of the Functional Languages are the developers, the University teaches developers to develop in Imperative or OO languages

That may be true for you, but I learned functional programming in college - alongside imperative languages.  I remember writing parsers in ML, flight simulator controllers in LISP and mathematical problem solvers in PROLOG (which to my mind is certainly closer to functional than imperative - although really it's more declarative).  I had friends who did Ph.D's specifically working on the performance problems in functional languages in an effort to help boost their adoption.

You're right that most developers are trained in OO programming - but when I was learning, OO was just appearing on the scene.  The question is why did OO come to dominate and functional programming did not?  Functional is potentially a bit harder for some people to think about - more like doing mathematics and less like doing engineering perhaps - but if the functional languages had delivered 5x speed boosts over OO, we'd all be writing in functional languages today.

To my mind, language performance (speed) has always been critical.  Remember how back in the day, Java adoption (over C++) took many many years because languages with garbage collectors were deemed "too slow" in many situations.  I remember writing an app in C++ and the same app in Java and getting a 3x CPU increase with the Java app.  Today Java runs much faster than the early versions did, processors are a lot faster and so the performance gap is smaller and obvious benefits of a better language mean Java dominates C++.  Also Java is vastly better (easier) than C++ at writing multi-threaded apps so it does better with the more cores that are prevalent now.

I think pure functional languages still face the same challenge today - they remain slower than their imperative counterparts and measurably and noticeably slower.  This is actually why almost all modern functional languages aren't pure - they allow mutable state, just so they can run faster.  I think that's a smart decision on their part and I also welcome the introduction of functional elements into the imperative languages.

I guess we can all agree we'd like to see the functional elements succeed and if they do, more and more developers will become comfortable with that way of approaching problems.

I learned Prolog at the University, I win 2 national challenges and build interpreters for the Web 3.0 with it.

Considering that JavaScript, Perl, Python, Ruby, ... are all functional languages and are in use in allot of systems. It seems to me that performance difference isn't the most important issue after all. The performance of most of the systems are more influenced by the Network or Disk issues then by the specific language.
krakatoaAuthor Commented:
In which case, I'd be intrigued to know what thoughts you may have on the fact that, say in Java, you find yourself in a Class system, whether you like it or not. Is that fact, in itself, already not 'prejudicial' to functional efficiency? By that I mean that once 'inside' a class so to speak, hasn't any potential downside performance already been mitigated, and access to the functional part of the API then as close as it would be via a purely functional language - i.e. you can go right ahead and write your methods?
JavaScript, Perl, Python, Ruby, ... are all functional languages

I think we have a different definition of functional.  To me a functional language's most important property is that it has no mutable state - no assignments (changing of values) is allowed.  From that, you get the "no side effects" property from functions and the support for parallelism etc.

JavaScript, Perl, Python are all typically used imperatively - with assignments and mutable state.  It might be possible to treat them as functional languages - in the same way that you could do that with Java before 8 if you just never used assignments - but it's not the common usage.  So I don't think we can infer that functional languages are in use in a lot of systems - since most of the common usage of those languages is for imperative programming.

To me those languages are dynamic languages (where types are inferred and checked at runtime, rather than at compile time).  Which is an interesting set of languages - but different (at least in my mind) from functional languages (which avoid mutable state and side-effects).  It's true that most functional languages are dynamic - but I don't think the reverse is true (not all dynamic languages are functional).

It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.