Summary: Most Java/OOP developers I know are interested in Functional Programming (FP). They want to make their code more reliable, testing easier, and want to gain performance advantages from multiple computer cores. The problem they have is that all the FP literature is about “programming in the small”, and what they need right now is a good example of a complete FP system (programming in the large), one that includes a UI, database, web services, etc. In this article I explore that problem from the perspective of Java/OOP developers, and offer the 80/20 rule I follow today for building systems with FP in mind.
Composition
I ran across some great thoughts from Erkki Lindpere on zeroturnaround.com yesterday. First this:
“I think the real composability and reusability in object-oriented code doesn’t come from object-oriented design at all: it comes from abstraction and encapsulation.”
Love to see a complete FP app
That’s good, but the highlight below shows my favorite thought:
That’s great stuff. All the Java/OOP developers I know ask for the same thing.
OOP vs FP “Smackdown”
I prefer a little entertainment in presentations, so I tweeted last week that I’d love to see an “OOP vs FP Smackdown”, where a developer from each camp creates the same application, side by side. They’d develop something like a social network application with a GUI, database, and web services, and have their code projected onto screens so the audience could compare the two approaches. They wouldn’t have to write all the code live, they could copy and paste like crazy, or discuss pre-existing code.
Since this presentation is primarily for Java/OOP people, the OOP discussion could be kept short; most of us Java devs know OOP, right? It’s the FP we’re interested in, so I’d give the FP presenter most of the stage time.
I think this would be an awesome presentation at Scala Days or a similar conference.
(Background: Somewhere around the year 2000 when I ran a small software consulting company, we did a “UML (Waterfall) vs Agile Smackdown” that was well received. It really highlighted the differences between the two approaches.)
FP devs usually talk about algorithms
Coming from the Java/OOP world, I completely understand Erkki’s statement. I can’t recall ever seeing an article or presentation where an FP advocate says, “Here’s how I build a GUI”, or, “Here’s how I write my database code.” Based on my experience, when an FP advocates talk about FP, they’re talking about algorithms.
To be clear, I don’t write this as an attack on the FP community; I just want to emphasize that this is what the OOP people are wondering. The OOP people are saying,
“FP guys, you have our attention, we’re interested in FP, but we don’t understand how we’re supposed to build a complete application.”
What I know about building FP programs
I’m not a functional programming expert, but hopefully I’m getting better. I researched this topic a lot for the Scala Cookbook, and have used FP techniques for the past two years when writing my own applications.
I can confirm that FP code is easier to test; I wrote about this in the “Idioms” chapter of the Cookbook. This is a great thing about Scala: It’s flexible, so you can write OOP and/or FP code. This lets you get started today, and your code will improve and become more Scala-like as you go on.
The short answer I can offer is to follow the 80/20 rule when building your applications:
- Write the core of your code -- the 80% -- in a functional way. Think of this as “the cake”.
- Write the GUI, database, and other non-FP code in the usual (OOP) way. Think of this as “the icing” on top of the cake. (The icing represents the thin layer of interaction between your FP cake and the outside world.)
(I believe I first read about this concept in the book, Beginning Scala, but I could be wrong.)
When you think about it, a strict FP program:
- Can’t have a GUI
- Can’t read or write to files or the console
- Can’t read or write to a database or web services
Given those restrictions, what other choice do you have?
Follow up
See Eric Torreborre’s comment below, where he points out this resource: http://mth.io/talks/patterns-in-types-ylj
books by alvin
 |
 |
 |
 |
