[javajosh]

Funny, I've had it the other way: I was working on a project as a senior dev and had interns writing Godless functional code using Guava and Functional Java, and having a grand old time seeing how much concurrent code they could fit into a single statement.

The fact is that Java is not a functional language and to bolt on functional pieces and then ignore the imperative, OO nature of Java is stupid. Don't get me wrong, I love functional programming, but Java is not and will never be a functional programming language, and developers that hate on programmers who use a language in the manner in which it was intended to be used are the real fools.

It is a poor programmer indeed that writes pathological code (and functional code in Java is pathological) and then blames his team for not understanding it.

[flatline3]

There are significant lessons to be learned from functional programming, the least of which is the value of immutability in making complex systems comprehensible.

Immutability is almost completely necessary for easy-to-understand concurrency, and extremely helpful in designing easy-to-understand APIs and operations on in-memory-models.

It is a poor programmer indeed that discards the lessons of FP and instead writes purely imperative OO. Your interns may have been writing bad code, but it wasn't the "functional" part that was the problem.

[kamaal]

>>It is a poor programmer indeed that discards the lessons of FP and instead writes purely imperative OO. Your interns may have been writing bad code, but it wasn't the "functional" part that was the problem.

Functional code is not Idiomatic Java code, 99.99% of Java code, practices and projects do not have it. Now when you go and bolt functional code on top of it, you are putting a tough puzzle on top of the code.

Don't be surprised if people cannot understand such code. In fact its bad programming to write non idiomatic code in a language. It confuses people, puts wrong patterns and paradigms and places where they don't belong. The language syntax struggles to support such semantics and often the code looks like a difficult puzzle in itself. Such code is very difficult to maintain and saps your energy is focusing on the wrong issues.

[flatline3]

It's bad code to write idiomatic mutable imperative Java. I'm not willing to write worse code just because bad engineers can't get their head around basic concepts that are integral to reliability, composability, maintainabiliy, and correctness.

Maintaining 'idiomatic' Java written by an 'average' developer is far more difficult and disheartening than maintaining well-written Java based on lessons from FP.

[kamaal]

In this case you shouldn't use Java at all. Because if your use case requires functional programming then you must use a functional programming language. Force fitting a non native paradigm to a tool and then calling those who don't understand it as bad is not fair.

I'm good != Others are bad.

>>Maintaining 'idiomatic' Java written by an 'average' developer is far more difficult and disheartening than maintaining well-written Java based on lessons from FP.

More than 90% of the Java projects I know are chosen to written in Java because its easy, cheaper, quicker to hire the 'average developer'. And not because of the merits of Java itself. These days 'Knows to use eclipse' == 'Knows Java', even if all the programmer knows is basic syntax, its assumed he can code in Java using intellisense and code complete.

Most of the Java code written today is tool generated, any way.

[javajosh]

The benefits from immutability are well-known outside the functional world. Josh Bloch harped on that (and rightly so) quite a lot in "Effective Java".

Immutability in Java is great, and doesn't have a functional corequisite.

[flatline3]

Immutability generally requires and/or benefits from programming in a functional style.

[javajosh]

Now you are trolling, but since the community has long since moved past this news item, I'm just going to point it out and move on myself.