Friday, November 25, 2022
You can program functionally in any computer language
A few days ago I wrote a comment on The Orange Site that seemed to strike a chord there. The comment was about applying a few principles of functional programming in any language (well, maybe not BASIC from the 70s or 80s, but these versions of BASIC aren't used much these days). There's no need for functional application, functional composition, first class functions, monads, (“Monads! How do they work?”) or even currying. No, I feel like you can get about 85% of the way to functional programming by following three simple principles.
Don't use global variables
This has the biggest effect on programming and it's been a well known principle for a long time, even before functional programming was a thing. Globals make it difficult to reason about code, since some function elsewhere can make an arbitrary change to a variable that can affect code called later on (or “spooky action at a distance” as Uncle Albert used to say).
While no global variables is the desirable goal,
I realize that it's not always possible to achieve and that threading global state through a program might be difficult,
but it does make for an interesting excersize to attempt it.
I recently went through the motions of removing all global variables from mod_blog.
I've always wanted to reduce the number of global variables and in late August I felt it was finally time to do so
(the fact that I was frustrated by the micromanagement style of the Enterprise Agile system that was being forced on us at work had nothing at all to do with the sweeping and rapid changes.
Nothing at all <cough> <cough>).
Yes,
I had to snake a bit of state information throughout the code,
but it wasn't nearly as bad as I thought it would be.
And as a side effect, it does make it easier to test individual functions as there is no more global state to worry about (although I do need to finish talking about unit testing at some point).
Treat function parameters as immutable
This is the extreme take. A less extreme take is “treat reference parameters as immutable.” If the language you use passes variables by value, then there's less need to keep the parameters immutable as they won't change data from the function caller's perspective. But reference variables? Or variables passed by pointer in C/C++? Those you want to treat as constant data as much as possible. This again, makes it easier to reason about a function as it will only work on the values given to it, and not change them (that “spooky action at a distance” thing again).
If you can't avoid mutating parameters, at least try to indicate any possible mutation in either the function name or it's signature to let another programmer know what to expect.
Separate I/O from processing
Of the three principles, this is probably the easiest to implement. Gather the data, process the data, send the results. And if you can't do so for reasons (like there's too much data to fit into memory) there are are a few methods to keep them logically separated, for instance:
- input as much as you can handle, process that batch, send it out, repeat;
- have the processing code call a (possibly configurable) function for input and output (admittedly, this may be easy or hard depending upon the language);
- get more memory.
Even if you don't need the flexibility of accepting different input or output methods, keeping the processing separate makes it easier to test the processing. Lord knows I would have loved it if “Project: Lumbergh” had a single entry point for dealing with the “business logic”—it would have made testing so much easier than it was (but that's no longer my concern).
So even if you can't switch to a functional programming langauge, that doesn't mean you can't apply the principles above and get most of the benefits of functional programming in a non-functional language. And the more that you can apply the principles above, not only will it make it easier to reason about code ina non-functional language, I think it will make learning an actual functional programming language easier. You might also want to read “Writing Video Games in a Functional Style. This is where I picked up on these principles in the first place (and it's sad that James Hague isn't writing anymore, but perhaps he said all he needed to).
