When you hear the term “pure functional programming”, does it translate into “dogmatist programming” in your head? Maybe it should translate into “simple programming” instead. Now, if you think that that statements just proves I’m one of the dogmatists, then humor me for a minute.
Let’s try to draw a picture of how a method from an object-oriented language relates to its environment. Let’s start with a simple case, a
bar() call on a
foo object that takes no inputs and gives no outputs.
I am using dotted lines to represent optional components, because really, instead of having an object involved we could have a static method that reads input from the outside world:
Or it could write output to the outside world:
And we could of course have a return value:
And that return value could originate from different parts of the method; it could have multiple exit points:
And then, there is always input parameters:
Some languages even allow for output parameters:
And don’t forget that you could throw an exception:
Actually, you could throw exceptions from different locations; they might bubble up from underlying function calls; who knows how many exceptions might actually get thrown:
And if there is some global state or a singleton or something, you could be interacting with that:
That, ladies and gentlemen, is object-oriented programming. Say whatever else you like about it, it is not particularly simple.
By contrast, here’s how functional programming works. You always have input and output, even if it is only the placeholder unit.
That’s a pure function. Purity is not about elitist dogmatism. It is about simplicity.