OO to FP: Transition
OO to FP: Transition
Join the DZone community and get the full member experience.Join For Free
Atomist automates your software deliver experience. It's how modern teams deliver modern software.
Since I've been doing primarily object-oriented development for many years, I have a perspective that is different than someone just learning to program. I think that a person with an OO background might need a slightly different introduction to FP than someone coming in with a clean slate -- it certainly seems that way to me, as I don't feel a lot of the "intro" material emphasizes the differences that an OO person would find important. The point of my posts on this topic is to capture my own experience learning FP before I forget what my "angle" was (and then myself become useless to an OO person about to go through the same process).
This experience reminds me of my last development paradigm shift, when a number of my co-workers and I decided to learn object-oriented analysis, design and programming (in those pre-agile days, huge emphasis was placed on the difference between those three phases!). I worked in a research lab, and we wrote mostly in C and Fortran. Some of use wanted to become really grounded in OOA/D/P before we started writing code (I was in this camp) and some of us just wanted to start hammering out code. I could not understand these people in the latter camp. How could you develop object-oriented code without learning what object-oriented analysis is? And you're not even going to learn about OOD? You're skipping the analysis and design phases? You're just going to be writing Fortran code in C++! Ahh! I was young and thought I would live forever. Actually, I thought about death a lot (actually, I didn't).
We used Smalltalk and C++. Although I was really happy with my Smalltalk tic-tac-toe program (on a Mac), I knew from the beginning that this platform was not going to rule the OO world. C++ had a lot going for it (and still does): it was a bridge technology from C to object orientation, and the results speak for themselves. Of course Java has been hot for many years, too, but frankly I suspect that the success C++ had in bridging procedural developers to OO may have been the big enabler for Java.
One thing about FP: I'm not sure I see an equivalent bridge technology; not an out-of-the-park winner, at least. I appreciate the FP-inspired languages that run on the JVM; the JVM seems like a potential bridge technology. For example, I could probably convince my co-workers to accept some Scala code on our Java platform. But I don't feel very enthused working with Scala. If you read my posts on Seven Languages in Seven Weeks, you know I like Erlang a lot. I've spent a lot of time learning Erlang, but I'm just now giving up on it for a number of reasons, the main one being that I just don't see it becoming a Java or a C++. I don't feel particularly competent in my ability to predict which FP language is likely to prevail, though. I won't be surprised by what happens, but I also know it won't be something I could have predicted, as things seem a little less clear-cut than the competition between OO languages years ago.
So, here is what I have decided to do: I'm going to learn Haskell, using the O'Reilly book Real World Haskell. My goal is to get a good education in functional programming and not to worry at this time about who's going to "win", and I feel Haskell is a great language to choose to learn FP. As I learn, I'll collect my thoughts and mention what jumps out at me, as an OO person, and hopefully some other OO people will find the commentary useful.
I don't hold strong opinions on any of these topics. Mostly I just want to learn FP and hopefully help other OO developers do the same. I would also like to be especially proficient in one FP language, so I've made my choice. If you are interested in Haskell, or are a Java developer interested in FP, I hope I provide something useful to you. My first post is coming in a couple of days.
Opinions expressed by DZone contributors are their own.