OOP vs FP: a couple of thoughts
2014-12-10

I’m learning functional programming and writing things down as I go. Some of my understanding may be incomplete or wrong, and I expect to refine it in the fullness of time.

The key difference between these two programming paradigms is the absence of state in functional programming.

An OOP program is like a complicated mechanism full of gears, levers and pulleys which are constantly moving as time goes on. Inputs are dropping into the mechanism, causing all sorts of movement and reconfiguration, and outputs are popping out of the mechanism as a result. For the most part, this mechanism is meant to tick along for a long time, and the state of the mechanism affects what’s going to happen to any given input.

An FP program, in contrast, is more like a labyrinth with little transmutation portals strewn throughout. Inputs travel through this labirynth (with different inputs taking different paths), and get transformed as they go through the portals. It is timeless, and it’s only meant to produce an output from an input. The same input will always produce the same output.

So if an FP program has nothing to do with time, then how can it do anything other than a single run over the input? How can it work for dynamic, interactive systems?

Well, an FP program can look like a continuously running mechanism if it’s combined with lazy evaluation (at least in Haskell). In essence, we can consider that the input is a long (potentially infinite) list which is being drip fed to the program, and it so happens that the program produces outputs during the processing of these bits of input.

The difference from OOP is that in a functional program, the dynamic nature of the output is not controlled by a mechanism ticking along, but rather by the cadence of the inputs dropping into the labyrinth. In other words, any time-dependent aspects of the output are side effects determined by factors external to the program itself.

I’ve seen some counterpoints to the viability of this idea:

So I need more clarity on this.