Hacker News Reader

Comment by twic | Hacker News Reader

Nor in mine. I worked on some codebases in Java 6/7 with a team who yearned for functional programming. They used various libraries that tried to support a functional style - Guava for the moderates, FunctionalJava for the zealots, lambdaj for those who liked to be different.

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?

View on HN

But here you are talking about functional style rather than functional programming on a definitional level. I do agree that Java is not well suited for FP. I think you can apply the base theory of FP to the language, but it may be little more than an academic exercise.

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.

Think about what following the most basic aspects of functional programming would mean in Java:

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);

you have:

    newRectangle = rectangle.stretched_x(2.5);

Even this very small move here moves you way outside Java as typically programmed. This means further that even at this level (the most basic level of FP), your program will:

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.

You're conflating a couple of things here: encapsulating state, and mutability of state. Your examples are about mutability. But immutability is already standard practice in Java - standard enough that it's one of the items in Josh Bloch's 2001 book 'Effective Java', the bible of righteous Java programmers:

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:

https://news.ycombinator.com/item?id=7898294

Reply on news.ycombinator.com