# Functional Programming - A paradigm for declarative, predictable code

## Introduction

**Functional Programming (FP)** is a programming paradigm where software is built by composing **pure functions**, avoiding shared state, mutable data, and side-effects. It treats computation as the evaluation of mathematical functions. Instead of describing *how* to achieve a result (imperative programming), you describe *what* the result is (declarative programming).

This paradigm has gained significant traction because it helps manage the complexity of modern applications, especially those involving concurrency and complex state management. Programs written in a functional style are often easier to reason about, test, and debug.

## Core Concepts

### Pure Functions

A function is **pure** if it adheres to two rules:

1.  **The same input always returns the same output.** The function's return value depends solely on its input arguments.
2.  **It produces no side effects.** A side effect is any interaction with the "outside world" from within the function. This includes modifying a global variable, changing an argument, logging to the console, or making a network request.

<!-- end list -->

```javascript
// Pure function: predictable and testable
const add = (a, b) => a + b;
add(2, 3); // Always returns 5

// Impure function: has a side effect (console.log)
let count = 0;
const incrementWithLog = () => {
  count++; // And mutates external state
  console.log(`The count is ${count}`);
  return count;
};
```

### Immutability

**Immutability** means that data, once created, cannot be changed. If you need to modify a data structure (like an object or array), you create a new one with the updated values instead of altering the original. This prevents bugs caused by different parts of your application unexpectedly changing the same piece of data.

```javascript
// Bad: Mutating an object
const user = { name: "Alice", age: 30 };
const celebrateBirthdayMutable = (person) => {
  person.age++; // This modifies the original user object
  return person;
};

// Good: Returning a new object
const celebrateBirthdayImmutable = (person) => {
  return { ...person, age: person.age + 1 }; // Creates a new object
};

const newUser = celebrateBirthdayImmutable(user);
// user is still { name: "Alice", age: 30 }
// newUser is { name: "Alice", age: 31 }
```

### First-Class and Higher-Order Functions

In FP, functions are **first-class citizens**. This means they can be treated like any other value:

  * Assigned to variables
  * Stored in data structures
  * Passed as arguments to other functions
  * Returned as values from other functions

A function that either takes another function as an argument or returns a function is called a **Higher-Order Function**. Common examples are `map`, `filter`, and `reduce`.

```javascript
const numbers = [1, 2, 3, 4];
const isEven = (n) => n % 2 === 0;
const double = (n) => n * 2;

// `filter` and `map` are Higher-Order Functions
const evenDoubled = numbers.filter(isEven).map(double); // [4, 8]
```

## Key Principles

  - **Declarative Style**: Focus on *what* the program should accomplish, not *how* it should accomplish it. An SQL query is a great example of a declarative style.
  - **No Side Effects**: Isolate side effects from the core logic of your application. This makes your code more predictable.
  - **Function Composition**: Build complex functionality by combining small, reusable functions.
  - **Referential Transparency**: An expression can be replaced with its value without changing the behavior of the program. This is a natural outcome of using pure functions and immutable data.

## Implementation/Usage

The core idea is to create data transformation pipelines. You start with initial data and pass it through a series of functions to produce the final result.

### Basic Example

```javascript
// A simple pipeline for processing a list of users
const users = [
  { name: "Alice", active: true, score: 90 },
  { name: "Bob", active: false, score: 80 },
  { name: "Charlie", active: true, score: 95 },
];

/**
 * @param {object[]} users
 * @returns {string[]}
 */
const getHighScoringActiveUserNames = (users) => {
  return users
    .filter((user) => user.active)
    .filter((user) => user.score > 85)
    .map((user) => user.name.toUpperCase());
};

console.log(getHighScoringActiveUserNames(users)); // ["ALICE", "CHARLIE"]
```

### Advanced Example

A common advanced pattern is to use a reducer function to manage application state, a core concept in The Elm Architecture and libraries like Redux.

```javascript
// The state of our simple counter application
const initialState = { count: 0 };

// A pure function that describes how state changes in response to an action
const counterReducer = (state, action) => {
  switch (action.type) {
    case 'INCREMENT':
      return { ...state, count: state.count + 1 };
    case 'DECREMENT':
      return { ...state, count: state.count - 1 };
    case 'RESET':
      return { ...state, count: 0 };
    default:
      return state;
  }
};

// Simulate dispatching actions
let state = initialState;
state = counterReducer(state, { type: 'INCREMENT' }); // { count: 1 }
state = counterReducer(state, { type: 'INCREMENT' }); // { count: 2 }
state = counterReducer(state, { type: 'DECREMENT' }); // { count: 1 }

console.log(state); // { count: 1 }
```

## Common Patterns

### Pattern 1: Functor

A **Functor** is a design pattern for a data structure that can be "mapped over." It's a container that holds a value and has a `map` method for applying a function to that value without changing the container's structure. The most common example is the `Array`.

```javascript
// Array is a Functor because it has a .map() method
const numbers = [1, 2, 3];
const addOne = (n) => n + 1;
const result = numbers.map(addOne); // [2, 3, 4]
```

### Pattern 2: Monad

A **Monad** is a pattern for sequencing computations. Think of it as a "safer" functor that knows how to handle nested contexts or operations that can fail (like Promises or the `Maybe` type). `Promise` is a good practical example; its `.then()` method (or `flatMap`) lets you chain asynchronous operations together seamlessly.

```javascript
// Promise is a Monad, allowing chaining of async operations
const fetchUser = (id) => Promise.resolve({ id, name: "Alice" });
const fetchUserPosts = (user) => Promise.resolve([ { userId: user.id, title: "Post 1" } ]);

fetchUser(1)
  .then(fetchUserPosts) // .then acts like flatMap here
  .then(posts => console.log(posts))
  .catch(err => console.error(err));
```

## Best Practices

  - **Keep Functions Small**: Each function should do one thing well.
  - **Use Function Composition**: Use utilities like `pipe` or `compose` to build complex logic from simple building blocks.
  - **Embrace Immutability**: Use `const` by default. Avoid reassigning variables. When updating objects or arrays, create new ones.
  - **Isolate Impurity**: Side effects are necessary. Keep them at the boundaries of your application (e.g., in the function that handles an API call) and keep your core business logic pure.

## Common Pitfalls

  - **Accidental Mutation**: JavaScript objects and arrays are passed by reference, making it easy to mutate them accidentally. Be vigilant, especially with nested data.
  - **Over-Abstraction**: Don't use complex FP concepts like monad transformers if a simple function will do. Prioritize readability.
  - **Performance Misconceptions**: While creating many short-lived objects can have a performance cost, modern JavaScript engines are highly optimized for this pattern. Don't prematurely optimize; measure first.

## Performance Considerations

  - **Object/Array Creation**: In performance-critical code (e.g., animations, large data processing), the overhead of creating new objects/arrays in a tight loop can be significant.
  - **Structural Sharing**: Libraries like `Immer` and `Immutable.js` use a technique called structural sharing. When you "change" an immutable data structure, only the parts that changed are created anew; the rest of the structure points to the same old data, saving memory and CPU time.
  - **Recursion**: Deep recursion can lead to stack overflow errors. While some languages support **Tail Call Optimization (TCO)** to prevent this, JavaScript engines have limited support. Prefer iteration for very large data sets.

## Integration Points

  - **UI Frameworks**: FP concepts are central to modern UI libraries. **React** encourages pure components and uses immutable state patterns with Hooks (`useState`, `useReducer`).
    \-- **State Management**: Libraries like **Redux** and **Zustand** are built entirely on FP principles, particularly the use of pure reducer functions.
  - **Data Processing**: FP is excellent for data transformation pipelines. It's often used in backend services for processing streams of data.
  - **Utility Libraries**: Libraries like **Lodash/fp** and **Ramda** provide a rich toolkit of pre-built, curried, and pure functions for everyday tasks.

## Troubleshooting

### Problem 1: Debugging composed function pipelines

**Symptoms:** A chain of `.map().filter().reduce()` produces an incorrect result, and it's hard to see where it went wrong.
**Solution:** Break the chain apart. Log the intermediate result after each step to inspect the data as it flows through the pipeline.

```javascript
const result = users
  .filter((user) => user.active)
  // console.log('After active filter:', resultFromActiveFilter)
  .filter((user) => user.score > 85)
  // console.log('After score filter:', resultFromScoreFilter)
  .map((user) => user.name.toUpperCase());
```

### Problem 2: State changes unexpectedly

**Symptoms:** A piece of state (e.g., in a React component or Redux store) changes when it shouldn't have, leading to bugs or infinite re-renders.
**Solution:** This is almost always due to accidental mutation. Audit your code to ensure you are not modifying state directly. Use the spread syntax (`...`) for objects and arrays (`[...arr, newItem]`) to create copies. Libraries like `Immer` can make this process safer and more concise.

## Examples in Context

  - **Frontend Web Development**: The **Elm Architecture** (Model, Update, View) is a purely functional pattern for building web apps. It has heavily influenced libraries like Redux.
  - **Data Analysis**: Running a series of transformations on a large dataset to filter, shape, and aggregate it for a report.
  - **Concurrency**: Handling multiple events or requests simultaneously without running into race conditions, because data is immutable and shared state is avoided.

## References

  - [MDN Web Docs: Functional Programming](https://www.google.com/search?q=https://developer.mozilla.org/en-US/docs/Glossary/Functional_programming)
  - [Professor Frisby's Mostly Adequate Guide to Functional Programming](https://mostly-adequate.gitbook.io/mostly-adequate-guide/)
  - [Ramda Documentation](https://ramdajs.com/docs/)

## Related Topics

  - Immutability
  - Functional Reactive Programming (FRP)
  - The Elm Architecture
  - Algebraic Data Types