I attended an interesting talk the other night at the Milano XP User Group. Uberto Barbini was sharing his thoughts and experiences over using Object-Oriented and Functional Programming together.
Uberto showed us some production code, that he thought was a neat application of FP in a OOP context. The funny thing is that to my eyes it seemed that was neither FP nor OOP; it seemed procedural to me. Uberto argued that it was functional and not procedural, because there was no global state involved; it was a self-contained transformation of data.
That got me thinking. Do I like that definition of “procedural”? I don’t think so. I think that you can tell procedural code when the thinking that goes behind that code is something like:
First I do this.
Then I do that.
If Zot Then I do Blah.
Else I do Blorgh.
When you think of a recipe, or a sequence of steps, then for me it’s procedural. Essentially “procedural” is to model the solution as a process.
On the other hand, functional programming, in my humble opinion, is about mathematical models. You model the problem and the solution with functions, sets, maps, trees and all those abstract and precise mathematical concepts.
What about Object-Oriented Programming then? My thinking about OOP has been in the past that OOP is a natural consequence of writing modular programs. An object is a hidden data structure with a visible collection of operations. Then I understood that this is just one way to look at OOP, and probably it’s the wrong one :-) This point of view is heavily influenced by mathematics (the idea that the operation on an object define a sort of algebra) and by procedural thinking (the idea that programs = data + procedures, just like the title of an old favourite textbook.)
I learned from reading GOOS that OOP is mostly about the messages. There are some intesting and tantalizing quotes from Alan Kay about that. Even more recently I read Object Thinking, and I came to understand that OOP is about modeling the problem with a community of autonomous agents. The way to make OOP shine is to build a simulation of the problem. And I remembered the thrill I once had when I first read about OOP. About imagining these little software robots going about their business inside my programs. An object that can “think” for itself and has a behaviour. Now *that* is what OOP is about!
Back to the original theme, now was the code that Uberto showed to us OOP, FP or procedural? It turns out that it depends! You can’t say by just looking at the code. It depends on the thinking that goes behind the code. Uberto thinks functionally when he thinks about this code. That makes it functional code for him.
Suppose that years later I inherit his codebase. If I have no access to Uberto, it’s pretty difficult for me to reconstruct his mental process. I will probably treat the code as procedural; or maybe OO depending on my way of thinking about this code.
So this is a pretty shocking thought, isn’t it? I thought you could look at a program and tell its paradigm, functional or procedural or OO, just by looking at the code. But I now think you can’t; the three paradigms are not different ways to code; they are different ways of thinking! Procedural thinking is about recipes: follow these steps. Functional thinking is about math: functions and sets. Object-Oriented is about simulations: many independent agents. And this explains why it’s difficult to do OO well. You have to learn a different way of thinking. This is something that I heard Francesco Cirillo say many times. Now I understand it a bit better :-)