Not in my experience or that of my colleagues, no. I'm a Haskell user and writing a book for learning Haskell. I'm friends with several Scalaz developers including the creator and people that have worked on similar libraries for other languages. I've also attempted to use FP idioms outside of Haskell.
You can't take it with you. At best you'll learn to eschew a few bad habits, but that's not FP nor does it bring anywhere near the same benefits.
None of them really worked well (for functional programming - Guava is excellent in other ways). Java just doesn't let you write the function-like classes concisely enough for it to be worth breaking code down as far as you need to to call it functional programming.
Plus, no higher-kinded types, so no functors. And what's functional programming without functors and their kin?
The problem with FP and Java is that FP and object encapsulation don't really go very well hand in hand. I.e. in Java you are encouraged to think about objects and their behavior, as encapsulating state. Encapsulated state in not a goal in any FP I have done -- rather the problem is solved by making state structures immutable.
But this doesn't mean you can't. It certainly won't look like Haskell though. It won't be idiomatic Java either. In fact it may be almost, though not entirely, unlike normal Java code.
1. No private attributes (all state is transparent and immutable). 2. All methods that transform an object return a transformed copy. So instead of:
rectangle.stretch_x(2.5);
newRectangle = rectangle.stretched_x(2.5);
1. Be unable to work with standard libraries without mixing paradigms
2. Be unable to be used in other projects because of the same problems.
Given that ABCL uses supertypes to allow round-trips between Java and Common Lisp, I am fairly sure that functors should be possible in Java, if not elegant.
https://books.google.co.uk/books?id=ka2VUBqHiWkC&pg=PA73#v=o...
It's not usually pursued with the same rigour as in many functional languages, but it would be absolutely normal to see a Rectangle class with a stretchedX method which returns a new rectangle rather than mutates its receiver.
Now, you might argue that despite what Bloch, and every other good Java programmer, says, "Java as typically programmed" still trades mostly in mutable state. Since Java is actually widely used in the real world, it's typically incompetently programmed, and so this is probably true.
Nonetheless, i am confident that Java code written using immutable objects could both use and be used by other code. I say this because it's what i and my colleagues have been doing for years.
I had a go at functors in Java a while ago. You're certainly right that it's not elegant:
And if the price we pay for this "worse is better" is buffer overflows and the ocassional crash and/or security exploit, that's hardly unsurmountable either. Life would be boring with perfectly perfoming programs anyway...
> Life would be boring with perfectly perfoming programs anyway...
To me, it sounds like you are trying really hard to rationalize why the current state of the industry is okay. I don't blame you for this, it's horribly depressing to believe otherwise and work in our industry. However, if your first sentence is true, why do you feel the need to justify it with "But C/C++ having crashes and exploits can be exciting"?
I sincerely believe that "effective" in some platonic rhealm of ideas is BS.
I only measure effective in actual effectiveness. Has it worked in the industry? Were products written with it? How evolved? How many use them? Etc...
U"most software in actual use is in X" is a checkable observation, that shows fitness to the task and an evolutionary advantage to X.
What was the cause of the advantage I don't care much, but I'm 100% sure it's not "just marketing" (on the contrary). And even if it was because "most programmers are idiots and can't comprehend Y which is better" that would still be an advantage of X -- as it's more suited to the available programmers pool.
Just don't come to me with platonic ideals of what "should" be used instead, let your Y language win in the real world, and then we talk.
>However, if your first sentence is true, why do you feel the need to justify it with "But C/C++ having crashes and exploits can be exciting"?
Because what I'm trying to convey is having software with buffer exploits is better than no software (better than the vast amounts of non-written software for Y languages that we rely everyday in its X language version: from all Operating Systems to all browsers).
EDIT: or to phrase it better, what is missing or hard to do that you feel has the biggest influence (some things are possible, but just way more complicated)? I don't have enough FP experience myself to judge that.
Can you write maintainable, sane, and performant C++ code that leverages immutable data structures, guarantees referential transparency, and eschews mutable state?
Certainly there are languages which don't support FP approaches well. But lack of utility is not the same as impossibility. If nothing else the exercise ("How far can you take FP in Java?") will teach you all kinds of things.
> Certainly there are languages which don't support FP approaches well. But lack of utility is not the same as impossibility. If nothing else the exercise ("How far can you take FP in Java?") will teach you all kinds of things.
My mistake then. I agree that seeing how far you can take FP in Java is a useful exercise.