3 ms·

My personal experience has been that Java 8 lambda plus deep class hierarchies can lead to some truly impenetrable code (to read that is). In practice mixing o

My personal experience has been that Java 8 lambda plus deep class hierarchies can lead to some truly impenetrable code (to read that is). In practice mixing oop and the meager functional tools (as you note) in Java can be really, really bad, and makes me weep at the future of Java development. I think teams need to decide what kind of code they're going to write, either 'functional' or oo. And if you are using Java 8 lambda's (and googles immutable collections for example) teams should strive to keep class/interface hierarhies shallow. I've been doing enterprise java development for 15 years, and the code I'm seeing now is kinda the nail in the coffin for Java for me. I don't want write or maintain that stuff, the next time I switch jobs I'll be looking at a pay cut, and python/django most likely. Or going into management.

bad_user 10y ago
The problem with working with closures is that stack-traces tend to become very hard to read, close to unusable sometime. Add asynchrony/concurrency to the mix and you've got a wonderful cocktail :-) Partial blame is on Sun/Oracle for not adding mutual tail-recursive calls optimizations to the JVM ;-) This is one of the challenges of FP. It makes debugging harder. But then FP code tends to be tested by means of laws described with QuickCheck, a superb automated testing tool that has ports to Scala, Ocaml, Clojure (that I know of) and it raises the quality of the code a lot.