TS Ep 56: Functional Programming Basics & Pure Functions

TL;DR (Quick Summary)

#

• Pure Functions must be 100% deterministic (same input always equals same output) and have zero side effects (no DOM manipulation, no network requests, no global state mutation).
• Referential Transparency allows pure functions to be safely replaced by their computed values, enabling aggressive caching (memoization) and thread-safe concurrency.
• The Core Pattern: In functional architecture, we do not execute side effects directly. Instead, pure functions return immutable descriptions of side effects, which are later executed by a runtime engine (like Effect-TS).
• Immediate Benefit: Adopting pure functions makes your codebase trivially easy to unit test without complex mocking frameworks like Jest or Sinon.

1. Introduction: The Shift from OOP to FP

#

For decades, the software engineering industry has been dominated by Object-Oriented Programming (OOP). In OOP, we bundle data (state) and behavior (methods) together into classes. While this mental model maps well to real-world objects, it introduces a severe architectural vulnerability: shared mutable state.

When multiple methods or threads can modify the same piece of data, predicting the state of an application at any given point in time becomes computationally impossible. This leads to race conditions, phantom bugs, and massive test suites dedicated solely to setting up and tearing down mock databases.

Functional Programming (FP) takes a radically different approach. In FP, we treat functions as mathematical equations. State is never mutated. Data is immutable. And the primary engine of computation is the Pure Function.

2. What Exactly is a Pure Function?

#

A pure function is a strictly controlled execution context that abides by two uncompromising rules:

Rule 1: Total Determinism

#

Given the exact same inputs, the function will always return the exact same output, regardless of when it is called, where it is called, or how many times it is called. It cannot rely on hidden variables, system clocks, or random number generators.

Rule 2: Zero Side Effects

#

The function does not read from or modify anything outside of its own local scope.

A “Side Effect” is any interaction with the outside world. This includes:

• Mutating a global or closure variable.
• Making an HTTP network request (fetch()).
• Reading or writing to a Database or File System.
• Interacting with the Browser DOM.
• Executing console.log() or Math.random().
• Modifying the parameters passed into the function by reference.

The Problem with Impure Functions

#

Consider a standard enterprise application where developers frequently mix business logic with I/O operations.

// 🔴 IMPURE: Relies on hidden external state (taxRate)
let globalTaxRate = 0.2;

function calculateImpureTax(amount: number): number {
  // If globalTaxRate changes somewhere else in the codebase,
  // this function will suddenly return a different result for the same 'amount'.
  return amount * globalTaxRate;
}

// 🔴 IMPURE: Modifies external state and performs I/O
let totalSalesRecorded = 0;

function logSale(amount: number): number {
  // Side Effect 1: State Mutation
  totalSalesRecorded += amount;
  
  // Side Effect 2: I/O Operation
  console.log(`[SYS_LOG]: Recorded sale of ${amount}`);
  
  return amount;
}

If globalTaxRate changes during the lifecycle of the application, calculateImpureTax(100) will yield a different result today than it did yesterday. This hidden dependency makes the code fundamentally unpredictable and inherently difficult to debug.

The Pure Alternative

#

By ensuring our functions only rely on their explicit parameters, we create a perfectly predictable system.

// 🟢 PURE: Output is purely derived from explicit inputs
function calculatePureTax(amount: number, rate: number): number {
  return amount * rate;
}

// calculatePureTax(100, 0.2) is guaranteed to equal 20, until the end of time.

3. Impure vs Pure Functions Comparison

#

To solidify this concept, let’s look at a detailed comparison between standard imperative approaches and functional approaches across common scenarios.

4. Why Pure Functions Are Architecturally Essential

#

Adopting strict pure functions provides immediate, massive architectural benefits that scale perfectly as your codebase grows to hundreds of thousands of lines.

Trivial Unit Testing

#

In Object-Oriented systems, testing a service often requires complex Dependency Injection containers, Jest mocks, and Sinon spies to fake databases or global variables.

Because pure functions have no external dependencies, testing them requires zero setup. You simply pass an input and assert an output.

// No mocks required. No beforeAll() setups. Just pure data in, pure data out.
test("calculatePureTax should calculate 20% tax", () => {
  const result = calculatePureTax(100, 0.2);
  expect(result).toBe(20);
});

Referential Transparency and Memoization

#

Because calculatePureTax(100, 0.2) is guaranteed to equal 20, the expression is said to be Referentially Transparent. This means the compiler, or a caching layer, can literally replace the function call with the resulting value without changing the behavior of the program.

This unlocks aggressive performance optimizations like Memoization, where expensive mathematical computations are cached based on their input parameters.

Thread Safety and Concurrency

#

Pure functions do not mutate shared memory. In highly concurrent systems (like Node.js worker threads, or Go goroutines), you can spin up thousands of threads executing pure functions simultaneously without ever encountering a race condition, a deadlock, or needing a Mutex lock.

5. Step-by-Step: Refactoring Impure Code

#

Let’s walk through a practical example of refactoring an impure, heavily-coupled authentication service into a highly testable pure function pipeline.

Step 1: The Impure Implementation

#

Here is a standard, everyday Express.js style controller function. It mixes business logic, I/O, and external state all into one block.

// 🔴 Impure Authentication Controller
let loginAttempts = 0;

async function authenticateUser(username: string, plainTextPass: string): Promise<boolean> {
  // Side Effect: Mutating global state
  loginAttempts++;
  
  if (loginAttempts > 5) {
    // Side Effect: I/O Logging
    console.error("Too many login attempts");
    return false;
  }
  
  // Side Effect: Database I/O
  const dbUser = await database.query(`SELECT hash FROM users WHERE user = '${username}'`);
  
  if (!dbUser) return false;
  
  // Side Effect: Cryptographic hashing (Often relies on system randomness/timing)
  const isValid = await bcrypt.compare(plainTextPass, dbUser.hash);
  
  return isValid;
}

This function is a nightmare to test. You need a live database, you need to mock bcrypt, and you need to reset the loginAttempts counter before every test run.

Step 2: Isolating the Side Effects

#

To make this pure, we must extract the database call, the bcrypt comparison, and the attempt tracking out of the core business logic. We push the I/O to the edges of our system, leaving the center 100% pure.

Step 3: The Pure Implementation

#

// 🟢 Pure Business Logic
type AuthState = { attempts: number; lockedOut: boolean };
type UserRecord = { username: string; hash: string } | null;

// 1. Pure State Reducer (No mutation)
function calculateNewAuthState(currentState: AuthState): AuthState {
  const newAttempts = currentState.attempts + 1;
  return {
    attempts: newAttempts,
    lockedOut: newAttempts > 5
  };
}

// 2. Pure Decision Logic (No I/O)
function validateCredentials(
  inputPass: string, 
  userRecord: UserRecord, 
  compareHashFn: (input: string, hash: string) => boolean
): boolean {
  if (!userRecord) return false;
  
  // We inject the dependency (compareHashFn) instead of hardcoding bcrypt
  return compareHashFn(inputPass, userRecord.hash);
}

Notice how calculateNewAuthState and validateCredentials do absolutely no I/O. They take data and return data. They can be unit tested in milliseconds with 100% coverage. The actual execution of the Database query and the Bcrypt algorithm happens in a thin “glue” layer at the very edge of the application.

6. The FP Dilemma: Handling Real-World I/O

#

If pure functions cannot interact with the outside world—no databases, no networks, no logging—how do we build actual, useful applications? An application without side effects is just a server warming up a CPU.

In advanced Functional Architecture, we do not execute side effects; we return descriptions of side effects.

Instead of executing an API call, a pure function returns an immutable object (a data structure) that describes the intention to make an API call.

// Instead of executing the side effect directly:
function deleteUserImpure(id: string): void {
  // 🔴 Side Effect Execution!
  // fetch(`api/users/${id}`, { method: "DELETE" });
}

// We return a pure description of the action:
function deleteUserPure(id: string) {
  // 🟢 Pure Description! (Referentially Transparent)
  return {
    _tag: "DeleteUserAction",
    userId: id,
    url: `api/users/${id}`
  } as const;
}

The Separation of Concerns

#

By returning descriptions, your core business logic remains 100% pure, predictable, and testable.

Once your pure functions have composed these descriptions, they hand them off to a Runtime Engine located at the very edge of your program. The Runtime Engine interprets the descriptions and safely executes the dirty I/O side effects.

This revolutionary concept—separating Description from Execution—is the entire architectural foundation of Effect-TS.

7. Troubleshooting & Common Errors

#

When migrating to a Functional Programming mindset, developers often accidentally introduce impurity. Here are the most common errors and how to identify them.

Error 1: Implicit Date.now() Mutations

#

The Mistake: Using Date.now() or new Date() inside a function makes it impure because the output changes every millisecond.

// 🔴 Impure
function createReceipt(amount: number) {
  return { amount, timestamp: Date.now() }; 
}

The Fix: Pass the timestamp as an explicit argument.

// 🟢 Pure
function createReceipt(amount: number, currentTimestamp: number) {
  return { amount, timestamp: currentTimestamp }; 
}

Error 2: Array Parameter Mutation

#

The Mistake: Using .push(), .pop(), or .sort() on an array parameter mutates the original reference passed into the function.

[TypeError]: Cannot assign to read only property '0' of object '[object Array]'

(This error often appears when you try to use .sort() on a frozen array in React or Redux).

The Fix: Always copy the array before mutating it, or use immutable methods like .filter() and .map().

// 🔴 Impure
function sortUsers(users: string[]) {
  return users.sort(); // Mutates original array!
}

// 🟢 Pure
function sortUsersPure(users: readonly string[]) {
  return [...users].sort(); // Copies, then sorts!
}

Summary & Next Steps

#

In this episode:

• We defined Pure Functions as deterministic functions with zero side effects.
• We compared Impure and Pure implementations across common enterprise scenarios using Markdown tables.
• We observed how hidden external state creates unpredictable, difficult-to-test code.
• We refactored a highly-coupled authentication controller into a testable pure pipeline.
• We discovered that Functional Programming handles I/O by returning descriptions of side effects, rather than executing them directly.

However, pure functions are only half of the equation. If we pass objects into our pure functions, we must guarantee those objects are not mutated internally.

In Episode 57: Immutability & Readonly Data, we will explore how TypeScript enforces strict deep data immutability to eliminate state-based bugs entirely!