3 ms·

Think about what following the most basic aspects of functional programming would mean in Java: 1. No private attributes (all state is transparent and immutab

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.

twic 12y ago
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=onepage&q&f=false 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 https://news.ycombinator.com/item?id=7898294

twic 12y ago

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=onepage&q&f=false 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 https://news.ycombinator.com/item?id=7898294