The Functional Programming Myth: Why Backus Wasn't Just Chasing Syntax
Think functional programming is just about avoiding variables? Let's look at the real vision behind John Backus's work.
The Variable-Free Fantasy
Many developers believe that functional programming is simply a stylistic choice to avoid using ‘var’ or ‘let’ in their code. The popular belief is that if you don’t name your intermediate variables, you are somehow doing ‘pure’ functional programming.
The Myth: Syntax Over Substance
People often repeat that John Backus, the creator of Fortran and a pioneer of functional research, hated variables because they were ‘ugly’ or ‘messy.’ The common narrative suggests he wanted to force programmers to write code that looked like mathematical equations just to be different.
The Reality: The Von Neumann Bottleneck
Backus wasn’t interested in syntax; he was interested in architecture. In his famous 1977 Turing Award lecture, he identified the ‘Von Neumann Bottleneck.’ He argued that our programming languages were essentially just high-level wrappers for the CPU’s memory-to-processor traffic.
He proposed ‘function-level’ programming as a way to escape this. By composing functions directly—passing the output of one into the input of another without storing intermediate results in memory—he aimed to create programs that were easier to reason about mathematically and, crucially, easier to parallelize. He wanted to break the reliance on the sequential ‘fetch-execute’ cycle of hardware.
The Nuance: Why Variables Matter
Is the myth half-right? Yes. Variables are a source of state-related bugs. When you name a variable, you create a ‘place’ in memory that can be changed. However, the goal of functional programming isn’t to make code look weird; it’s to reduce the ‘surface area’ of state that a programmer has to track. Sometimes, naming an intermediate result makes code much more readable, even if it technically violates the ‘pure’ function-level ideal.
A Better Mental Model: Composition as Infrastructure
Stop thinking of functional programming as a way to avoid variables. Think of it as a way to build data pipelines. Instead of ‘storing’ and ‘retrieving’ data, you are ‘transforming’ and ‘piping’ it.
# Instead of creating stateful steps:
# data = load()
# data = filter(data)
# result = transform(data)
# Think in composition:
load() |> filter() |> transform()Takeaway
Next time you write code, don’t just focus on removing variables. Ask yourself: ‘Am I managing state, or am I defining a flow?’ Focus on the flow, and the variables will naturally take care of themselves.
