Perhaps I didn't state that well. I'll try again. I know what good OO looks like. I can apply SOLID and a lot of other techniques to make my class graph "corre

Perhaps I didn't state that well. I'll try again. I know what good OO looks like. I can apply SOLID and a lot of other techniques to make my class graph "correct". When I'm done, I have a well-decomposed mostly-isomorphic view of the problem domain (usually along with a lot of "helper" stuff thrown in.) If you know how good OO looks, and you look at your classes and they don't look that way? You can learn a lot by continuing to clean them up. Same goes for FP. But currying, partial application, and composition allows for a huge amount of code reduction (and corresponding better problem understanding) than OO. So as you "clean up" your functional code, you're learning much better refactoring skills than you ever would with OO. It's not surprising. OO is mainly concerned with where things go. Learn you some OO and you know where to put stuff. FP is mainly concerned with what things do. Learn you some FP and you'll learn how to make the computer do more with less code. Less code generally means less bugs and easier maintenance, but we can save that for another day. The point of my original post is that F# can let you learn both ways -- and move from OO to FP in an incremental, self-directed fashion. That's pretty cool.