Clojure Gazette 185: What is Functional Programming?

What is Functional Programming?

Issue 185 - August 08, 2016

Hi Functional Programmers,

I've been thinking about what functional programming is for a long time. People ask me all the time what it is and why they should care about it. I don't really have an answer for why they should care. If they're a programmer, they've already got their stack and their job. They're set for years to come, no need to change. In that way, preferring functional programming is just a matter of taste.

But the first question is difficult. What is functional programming? It's a hard question that deserves some tough thinking. Now before we get too deep into it, I have to mention that OOP has the same kind of identity crisis. What is OOP? The existential line of questioning usually terminates in quoting Alan Kay , the originator of the term:

OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. It can be done in Smalltalk and in LISP. There are possibly other systems in which this is possible, but I'm not aware of them.

It's a self-defeating definition to quote. It excludes languages traditionally considered OOP, presumably also the favorite language of the person doing the quoting. And then, ironically, LISP, a functional language, turns out to be object oriented as well. It just makes me think that these things are not that well defined. It's perfect for navel-gazing essays.

What is functional programming? I used to think of it as an awareness of pure and impure functions . A language is only as functional as the help is gives you to separate the pure from the impure. This conveniently let Haskell be very functional, since the type system helps be absolute about purity. And Clojure is pretty functional as well, because it uses immutable data structures and encourages pure functions. JavaScript is a little functional, but especially functional. Very convenient.

But I'm unsatisfied with that definition now. It excludes so many of the cool things about functional programming. Referential transparency is only a means to an end. There is something deeper in functional programming that goes beyond using immutable values and functions that don't have effects.

I reread John Hughes' classic paper Why Functional Programming Matters . In the paper, John Hughes explains that the important feature of functional programming is higher order functions (and laziness). Purity is only in the service of higher level abstractions. The essence is abstraction!

There is a bit of a Smug Lisp Weenie in me who resents Object Oriented Programming as we see it today. By not giving good means of abstraction, OO languages created a cottage industry of "Object Oriented Design" that includes "Design Patterns" . Cottage industries are signs that the tools don't do their jobs. People make money on the mismatch between the tool and its purpose. Anyone can cut a steak with a knife but it takes an expert to cut it with a spoon.

It all comes back to abstraction, lambdas, functions. And so the name functional programming. There's nothing new except more powerful hardware. It's a real renaissance of a constellation of old ideas about computation, abstraction, and organizing memory that were all but lost to history. They're found now and their rising popularity is letting us use them once again. They're directly influencing the entire industry. We're living in exciting times!

Well, with the last few issues I've had so many great discussions. I'm looking forward to your responses.

Rock on!

PS Want to get this in your email? Subscribe !
PPS Want to advertise to smart and talented Clojure devs ?