Why Your Object-Oriented Code is Driving You Crazy (And What Math Can Teach Us)

Part 1 of 4: From Code Chaos to Mathematical Zen

Picture this: It's 3 AM. You're debugging a production issue. Something broke—but what? A cascade of failures is rippling through your carefully architected system. You trace through modules, follow dependency chains, and ask yourself the age-old questions that haunt every developer:

• What broke?
• Why did it break?
• Will it cause a chain reaction?
• Are other modules going to fail now?
• Is the whole system going to catch fire?

If this scenario feels painfully familiar, you're not alone. This is the reality of building complex systems with Object-Oriented Programming (OOP). What started as elegant theory—encapsulation, inheritance, polymorphism—often becomes a tangled web of dependencies in practice.

The OOP Promise vs. Reality

Don't get me wrong. OOP dominates production systems and enterprise software for good reasons. It gave us powerful abstractions and ways to model real-world entities. But as our systems grow larger and more modular, something insidious happens.

A project begins small and manageable. Then it grows. We add modules, each with their own dependencies. We remove some modules, add new ones, introduce external libraries, and let others become obsolete. Before long, we've built a house of cards where touching one piece can bring down the entire structure.

As Joe Armstrong, creator of Erlang, put it: "The biggest problem with object-oriented programming is that it's all about objects. That's not how we think."

And Rich Hickey, creator of Clojure, was even more direct: "OOP to me means only one thing: global mutable state."

These aren't attacks on OOP—they're observations about what happens when we let complexity grow unchecked.

The Inheritance Problem

We've all heard "composition over inheritance" so many times it's become a mantra. But why did we need this mantra in the first place? Because inheritance, despite its theoretical elegance, often creates rigid, tightly coupled systems where changes in one class ripple through entire hierarchies.

Sure, encapsulation and abstraction remain essential. Polymorphism still offers flexibility and elegance. But when inheritance creates more problems than it solves, maybe it's time to question the paradigm itself.

Maybe It's Time for a Fresh Start

Instead of patching a leaky boat, maybe we need a new ship.

What if we kept the parts of programming that work well—data structures like lists, maps, tuples, and trees? What if we held onto primitive types like strings, booleans, and floats? There's nothing wrong with these building blocks.

But what could we add to restore predictability and robustness to our systems?

Let's borrow from something that's worked flawlessly for centuries: mathematics.

The Power of Mathematical Functions

Computer Science is, at its heart, a branch of applied mathematics. So what does math offer us that can fix this mess?

Functions—not methods or procedures, but pure mathematical functions.

A mathematical function is a relationship between two sets: an input set and an output set. Each input is mapped to exactly one output. No ambiguity. No hidden state. No side effects.

Consider this simple example:

f(x) = x²
f(6) = 36
f(5) = 25  
f(12) = 144

These functions always give the same output for the same input, because mathematics doesn't suffer from subjectivity. Call f(6) a thousand times, and you'll get 36 every single time.

This is called referential transparency—the idea that a function call can be replaced with its result without changing the program's behavior.

Purity: The Secret Sauce

Another core idea from mathematics is purity. Pure functions have no side effects.

Let's illustrate with a simple example:

# Pure function approach
x = 19
y = complex_function(x)  # Some long, complex computation
# What's x now? Still 19. Always 19.

Compare that to a typical imperative approach:

def add_item(my_list):
    my_list.append(42)

x = [1, 2, 3]
add_item(x)
print(x)  # Output: [1, 2, 3, 42]

Can we still be sure what x contained during the first call? Nope. Mutable state introduces uncertainty—the enemy of predictable software.

The Immutability Solution

What's the fix? Immutability—once a value is assigned, it can't be changed. We build new values instead of mutating old ones.

"But wait," you might ask, "isn't that wasteful? What if I need to update a massive structure like a million-element list?"

That's where persistent data structures come in. They preserve previous versions efficiently, allowing access to both old and new states without copying everything.

For example, representing a list of 1,000,000 elements as a tree (like a bit-partitioned vector trie) with a branching factor of 32 gives us log₃₂(n) complexity. That's just ~5 levels deep for a million elements. Incredibly efficient!

What This Unlocks

This simple principle—eliminating side effects—has powerful implications:

1. Eliminates entire classes of bugs: No more mysterious state changes
2. Order of execution doesn't matter: Since nothing depends on when something runs, expressions can be evaluated at any time
3. Compiler optimization: Runtimes can optimize execution however they see fit
4. Modularity becomes inevitable: Each function becomes a self-contained unit

Purity and immutability make modularity almost automatic. Each function becomes a black box you can plug in, reuse, test in isolation, or swap out with zero drama. You're no longer debugging mysterious interactions between distant parts of your codebase.

Instead, you're working with predictable, composable pieces—like LEGO bricks for your system's architecture.

The Formal Definition

After all that buildup, here's our formal definition:

Functional Programming (FP) is a paradigm where computation is treated as the evaluation of mathematical functions. It emphasizes pure functions, immutability, and avoiding shared state or side effects.

In functional programming:

• Variables are never reassigned—once a value is set, it stays that way
• Functions don't mutate state, don't interact with the outside world unexpectedly
• Functions just take input and return output, every time, with no surprises

What's Next?

But here's where it gets interesting. You might be thinking: "This sounds like programming with one hand tied behind my back. How do you actually build complex systems this way?"

That's exactly what we'll explore in the next post. We'll discover the "glue" that makes functional programming not just possible, but incredibly powerful—higher-order functions that let you compose simple pieces into sophisticated systems.

We'll also address the "medieval monk" criticism: the idea that functional programmers deny themselves programming's "pleasures" (like mutable state and loops) in hope of some abstract virtue.

Spoiler alert: The rewards are very real, very practical, and might just change how you think about building software forever.

Coming up in Part 2: "The Medieval Monk Was Wrong: Higher-Order Functions Are Your New Superpower"

Ready to discover the secret weapons that make functional programming not just viable, but incredibly powerful? We'll explore the "glue" that lets you build complex systems from simple, predictable pieces.

About This Series: This is Part 1 of a 4-part introduction to functional programming. We'll journey from the problems of traditional programming paradigms to the elegant solutions offered by functional approaches, culminating in real-world applications powering systems like WhatsApp and Discord.