* * * * *

            You can program functionally in any computer language

A few days ago I wrote a comment on The Orange Site [1] that seemed to strike
a chord there. The comment was about applying a few principles of functional
programming [2] in any language (well, maybe not BASIC (Beginner's All-
purpose Symbolic Instruction Code) 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? [3]”) 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 [4]. 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 [5] 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 (Input/Output) 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:

 1. input as much as you can handle, process that batch, send it out,
    repeat;
 2. have the processing code call a (possibly configurable) function for
    input and output (admittedly, this may be easy or hard depending upon
    the language);
 3. 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 [6]” 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 [7]).

* * * * *

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 [8]. 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).

[1] https://news.ycombinator.com/item?id=33630558
[2] https://en.wikipedia.org/wiki/Functional_programming
[3] https://www.youtube.com/watch?v=8GyVx28R9-s&t=112s
[4] https://github.com/spc476/mod_blog/releases/tag/v46
[5] gopher://gopher.conman.org/0Phlog:2022/10/08.1
[6] gopher://gopher.conman.org/0Phlog:2018/09/11.2
[7] gopher://gopher.conman.org/0Phlog:2022/10/05.1
[8] https://prog21.dadgum.com/228.html
---

Discussions about this page

You can program functionally in any computer language | Lobsters
 https://lobste.rs/s/prwwht

Email author at [email protected]