FP experts: It would help Java/OOP devs to see a complete app

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.

Back to top

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.”

Back to top

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.

Back to top

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.)

Back to top

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.”

Back to top

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?

Back to top

Follow up

See Eric Torreborre’s comment below, where he points out this resource: http://mth.io/talks/patterns-in-types-ylj

Back to top
Permalink

This is a FP program:

def printHello: IO[Unit] = IO(println("hello"))

Then the trick is call "run" only "at the end of the world", in the main method:

def main(args: Array[String]) = printHello.unsafePerformIO

This way, one very tiny part of the application is unpure, the entry point, and all the rest can be reasoned about because all methods are just returning values. So the icing should be more like 0.00001 %.

Now to do this effectively on a real you need to get a bit of library support, general with a Monad stack for reading, keeping state, writing and logging. That's where it would be nice to have a small sample app beyond the presentations. You have some elements here for example: http://mth.io/talks/patterns-in-types-ylj, but the full demo app would be even better.

Eric.

Permalink

There are FP GUI frameworks, see Reactive Banana.

Webservice communication / database interaction can be modeled similarly. They are essentially streams (see I/O monad).