I've been programming Java for a few years now, and I've dabbled in functional programming now and again. I'm thinking I should learn how to do the functional thing properly after having 'fun' with XQuery, so...
Are there traps my OO way of thinking can lead me into when I'm writing in a functional way?
The main thing you have to really wrap your mind around are the recursive functions instead of loops. Functional languages like haskell do not use loops, but instead build (tail) recursive functions which can exactly achieve the same thing.
Monads are quite tricky to understand, I refer you to this article to learn more about it.
Another big difference is that pure functional languages prefer immutable objects (functions, data structures, arguments). So if you want to keep track of state, you really have to pass it on as argument, or use specialized monads. Functions with side effects are nicely wrapped in special monad's so that you can distingush them from pure code.
In functional programming there are lot's of datastructures and the possibility to easily create new ones are endless. Instead of thinking in 'business objects' you might want to think in data types. These can be nicely used in pattern matching for your functions, so you can seperate functionality for different patterns in your datatype
data Gender = Man | Women
greet :: Gender -> String
greet Man = "Hello sir!"
greet Women = "Hey, how YOU doing ;)"
This are some of the big differences in programming, hopefully others will be able to add some more.
One thing you should always remember is that anything coded in an imperative language can also be coded in a functional language. Nothing is impossible!
Yes. :)
I don't know an easy/good summary, a lot of it is experiential, but here's a blog of mine that talks 'about' some of the issues...
How does functional programming affect the structure of your code?
(Kinda C# -> F# context, but a number of observations are language-independent.)
Most of my functional programming experience was with SML/NJ, and I had used Java previously.
As has been mentioned, the jump from procedural code with side-effects to side-effect-free recursive code is sizable, but the performance gains can be significant with a compiler that can take advantage of the optimizations possible with side-effect-free code.
There's a lot of conceptual overlap between classes and signatures / structures. But there are some subtle differences in the concepts of encapsulation. Structures define types that are (usually) opaque and the operators that may modify them, and signatures define the ways that one can operate on those types. This is similar to instances and classes, but in my experience there were some subtleties that were tricky, especially regarding such concepts as inheritance. I found that building several test cases that focused solely on ways I could access structs was extremely helpful.
As an OO-guy-turned-functional (though this is rather Haskell-centric), here's one of my biggest pitfalls.
I can heartily recommend The Little Schemer for getting used to recursion.