How immutability tamed the Wild West

When I started coding in the 1970s, I used BASIC. I remember discovering the cool new language feature called GOSUB that let you jump around easily in code and then return to where you had previously been. What a revelation!  

The language at the time had variables—but no constants. Parameters were not a thing—we had GOSUB!—and the notion of scope was completely unheard of. Everything was a global variable. Wild, right?

Immutability is the exact opposite of those Wild West days. Instead of “anything goes,” we get “tie everything down and nothing will slide around the back of the stage coach.”

And the notion of a constant was bizarre. I remember wondering why you’d ever want something like that when I learned about the idea. 

Even today, the notion of immutability is often given short shrift—a hangover from years gone by? But we now realize that all systems grow incredibly complex, and that immutability is a cornerstone of good, clean code. Today we have large, complex, multi-threaded applications that make the old way of thinking very troublesome. 

Change is bad

One of the first lessons that a new programmer should learn is that global variables are a crime against all that is good and just. If a variable is passed around like a football, and its state can change anywhere along the way, then its state will change along the way. Naturally, this leads to hair pulling and frustration. Global variables create coupling, and deep and broad coupling is the true crime against the profession.

At first, immutability seems kind of crazy—why eliminate variables? Of course things need to change! How the heck am I going to keep track of the number of items sold or the running total of an order if I can’t change anything?

Think of ordering a pizza. If you ask for a slice of pepperoni, you want it baked that way from scratch. You don’t want the cook taking yesterday’s veggie slice, scraping off the mushrooms, tossing on pepperoni, and reheating it. That’s gross. Variables and functions should work the same way. Don’t recycle the old slice, just give me a fresh one every time. You don’t want a changed slice—you want a new one.

Immutability is a powerful mental shift. Your mind needs to go from “change what is there” to “make a fresh, new thing without changing the old.” It is the idea that instead of editing what’s already there, you always make something new. That simple shift makes code safer and easier to reason about.

Pure functions are good

The key to immutability is understanding the notion of a pure function. A pure function is one that always returns the same output for a given input. Pure functions are said to be deterministic, in that the output is 100% predictable based on the input. In simpler terms, a pure function is a function with no side effects. It will never change something behind your back.

We’ve all had this experience:

function addPie(items: string[]) {
items.push('Apple Pie'); // side effect!
return items;
}

const order = ['Burger', 'Fries'];
const before = order;

const updated = addPie(order);

console.log('before:', before); // ['Burger', 'Fries', 'Apple Pie'] ← oops
console.log('updated:', updated); // ['Burger', 'Fries', 'Apple Pie']

Note the addPie function, which is impure and thus has a side effect. It changes the items array you send it. As a result, the before reference changes as well. Not good—you might not expect that. When data is shared, being mutable turns everything into a moving target that is hard to hit.

But if the function provides immutability:

function addPieImmutable(items: string[]) {
return [...items, 'Apple Pie']; // no side effects, new array
}

const order = ['Burger', 'Fries'];
const before = order;

const updated = addPieImmutable(order);

console.log('before:', before); // ['Burger', 'Fries'] stable
console.log('updated:', updated); // ['Burger', 'Fries', 'Apple Pie']

Here, the before reference remains unchanged. Because instead of updating the order, we created a new one (updated).

Change happens

Now this is a trivial example, but you can see how in the second version, there can never be a race condition or a battle for data because the order itself never changes. Instead, the order is recreated. Immutability doesn’t mean nothing changes; it means values never change once created. You still “change” by rebinding a name to a new value.

The notion of a “before” and “after” state is critical if you want features like undo, audit tracing, and other things that require a complete history of state. 

Back in the day, GOSUB was a mind-expanding concept. It seems so quaint today. Now, the big revelation is that immutability and pure functions help eliminate the surprises that those global variables wrought and bring consistency and reliability to our code.