On 15/07/2010 2:44 PM, jitesh dundas wrote:
I do not see much of Fp either in application side..I still do not think, that this is out of the big picture..where imp applications still use FP..
This may be an obvious statement, but I think its related to the size and complexity of the program, not that it is an "application". The bigger the code, the more protection (such as immutable data structures) helps, the more multithreading is important etc. When I hear "enterprise application" I tend to think of a simple application that talks to a back end, so would benefit less from FP (or to be more precise, are fine with OO). As the application complexity grows, the benefit of concepts such as immutability helps. Compare for example MS Word (which is a big application) to a simple data entry web form. Its not that its an "application" - its the size and complexity of the innards.
Just listened to a Clojure interview on Software Engineering Radio. I doubt I would ever use Clojure for a real application (LISP syntax? Yuck!), but the data structure and concurrency aspects I could really see the benefit of. Too many Java libraries you don't know if are thread safe internally. There are hidden, undocumented static variables hidden deep inside at times. Having the language make guarantees about immutability of data structures you can rely on sure can make it easier to go multithreaded at times. E.g. tried to use javax.mail to parse some email messages. You need a Session object to do a parse, but can you share session objects between threads? Is it safe to have one session object per thread? Could not work it out reliably from documentation. Its when things failed when sharing Session objects and worked when they were not shared that we knew what worked and would would not. (Yes, would could have read the source code and tried to work it out that way too!) Having the Session object or MIME parse tree of an email message immutable would have made it trivial to know what was safe.
Mind you building up immutable structures seems very wasteful. Feels really like you want builder pattern or setters so you can build up an object's state, then a way to go immutable after that. Clojure for example has hashmap support using a tree - adding a new value creates a new hashmap where much of the tree is shared with the old hashmap, but bits of the tree that need changing are created again. Building a hashmap of 100,000 values where no reference to any intermediate state is required seems really inefficient here. Having a (locally referencable) mutable data structure here seems perfect, with the ability to make it immutable later. (Do I recall Dick Wall saying the Google collections library tries to help here with mutable and immutable versions of data structures.) Personally I would love a programming language that using language scoping rules could guarantee that all references to the mutable version disappeared once the immutable handle to the structure came into scope - performance (no wasted effort or memory allocations or CPU) plus language guaranteed immutability (great for concurrency).
My favorite conceptual programming model at the moment? Light weight Actors interchanging guaranteed immutable message objects where Actors can have internal mutable state. Ideally the messages should also be serializable so you can send them around a farm of servers as well without code changes.
But I guess I am talking here about immutability of structures rather than functional programming as such.
Alan -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
