Coder Legion - Recent posts tagged functional-programming

Crafting a Functional Web Architecture

Sun, 14 Jun 2026 17:01:31 +0000

Building a web application with a functional mindset requires rethinking how data flows through your system. Instead of viewing your application as a collection of interacting objects that mutate over time, FP treats your application as a series of pure, transformational pipelines. * Component as a Pure Function: The core UI becomes a direct result of your data. In this model, $f(\text{state}) = \text{UI}$. Passing the exact same data into a component will always render the exact same visual output, completely eliminating visual side effects.

Immutability by Default: Instead of changing existing arrays or objects when a user interacts with the page, you always create fresh copies with the updated values. This makes tracking application changes incredibly straightforward.
Composition of Logic: Small, single-purpose functions are combined like Lego blocks to build complex business logic. You pipe data through validation, formatting, and rendering functions seamlessly.The Roadblocks of Going Fully FunctionalTransitioning to functional programming is rarely a smooth ride, especially in an ecosystem like the web which was fundamentally built on mutable concepts. The biggest hurdle is that the Document Object Model (DOM) is inherently stateful and mutable, creating an immediate architectural conflict.
The Steep Learning Curve: Concepts like currying, monads, higher-order functions, and purity can feel like an alien language to developers used to traditional procedural or object-oriented code.

Performance Overhead: Because immutability requires creating new objects rather than modifying existing ones, it can lead to frequent memory allocation and aggressive garbage collection, potentially slowing down low-end devices.

Ecosystem Incompatibility: A massive portion of third-party web libraries and legacy packages rely on classes and internal state mutation, making smooth integration a challenge.How We Overcome These ChallengesThe web development community hasn't ignored these pain points. Instead, modern tools and frameworks have evolved to bridge the gap between functional purity and practical web performance. We don't need to write purely theoretical code to reap the practical benefits of FP.

Virtual DOM and Reconciliation: Frameworks act as a protective translation layer. They allow you to write pure, functional component logic while the underlying engine handles the messy, mutable DOM updates efficiently behind the scenes.Structural Data Sharing: To fix the performance tax of immutability, modern libraries use smart data structures. Instead of copying an entire massive object, they reuse unchanged parts of the data tree, keeping memory usage remarkably low.

Pragmatic Hybrid Architectures: The most successful web projects don't chase absolute purity. They isolate side effects—like API calls and local storage access—to specific, controlled areas of the app, leaving the vast majority of the codebase clean, predictable, and fully functional.

Sumita
Web Developer

Functional Programming Patterns in JavaScript

Fri, 04 Jul 2025 20:18:30 +0000

Functional programming (FP) is a paradigm that emphasizes the use of pure functions, immutability, and declarative code. It has become increasingly popular in the JavaScript community due to its ability to produce reliable, maintainable, and scalable code.

This article explores essential functional programming patterns in JavaScript, offering insights into their use cases, benefits, and practical implementations.

Introduction to Functional Programming

Functional programming is built around the idea of composing programs using pure functions and avoiding shared state and side effects. JavaScript, while originally multi-paradigm, offers strong support for functional principles through its first-class functions and built-in methods like map, reduce, and filter.

Adopting functional patterns leads to:

Improved predictability and testability
Enhanced modularity and reusability
Cleaner, more readable code
Fewer side effects and state-related bugs

Pure Functions

A function is considered pure if it meets two criteria:

It returns the same output for the same input.
It does not produce side effects such as modifying external state or performing I/O operations.

Example:

// Pure function
const add = (a, b) => a + b;

// Impure function
let count = 0;
const increment = () => ++count;

Pure functions are deterministic, making them easier to test and reason about.

Function Composition

Function composition refers to combining two or more functions to produce a new function. This approach allows complex operations to be built from simpler ones, improving modularity and reusability.

Example:

const addOne = x => x + 1;
const double = x => x * 2;

const addOneThenDouble = x => double(addOne(x));

Generic compose utility:

const compose = (...fns) => x => fns.reduceRight((acc, fn) => fn(acc), x);

const process = compose(double, addOne);
process(3); // Returns 8

Function composition encourages declarative programming and simplifies data transformation pipelines.

Currying

Currying is a technique where a function with multiple arguments is transformed into a series of unary functions, each accepting a single argument.

Example:

const multiply = a => b => a * b;

const double = multiply(2);
double(5); // Returns 10

Currying promotes reusability and enables partial application of functions, which is particularly useful when composing higher-order functions.

Higher-Order Functions

Higher-order functions (HOFs) are functions that accept other functions as arguments or return them as results. JavaScript provides built-in HOFs such as map, filter, and reduce.

Examples:

Edit[1, 2, 3].map(x => x * 2);      // [2, 4, 6]
[1, 2, 3].filter(x => x > 1);  // [2, 3]

Custom higher-order function:

const withLogging = fn => (...args) => {
  console.log(`Calling with ${args}`);
  return fn(...args);
};

const add = (a, b) => a + b;
const loggedAdd = withLogging(add);

loggedAdd(3, 4); // Logs input and returns 7

Higher-order functions enable abstraction of control flow and behavior, allowing for clean and reusable code.

Partial Application

Partial application refers to pre-filling a function with some of its arguments, returning a new function that requires the remaining arguments.

Example:

const greet = (greeting, name) => `${greeting}, ${name}!`;

const sayHelloTo = name => greet('Hello', name);
sayHelloTo('Toni'); // "Hello, Toni!"

This technique is useful for creating specialized versions of general-purpose functions.

Recursion

Recursion is a technique where a function calls itself to solve a problem. In functional programming, recursion often replaces loops to maintain immutability.

Example:

const factorial = n => (n <= 1 ? 1 : n * factorial(n - 1));

factorial(5); // Returns 120

Recursion encourages the creation of elegant and expressive solutions, particularly when combined with immutable data structures.

Immutability

Immutability is a core principle of functional programming that involves avoiding mutations of data structures. Instead of modifying existing data, new copies are created with the necessary changes.

Examples:

const arr = [1, 2, 3];
const newArr = [...arr, 4]; // [1, 2, 3, 4]

const obj = { name: 'Toni' };
const updated = { ...obj, age: 35 }; // { name: 'Toni', age: 35 }

Libraries such as Immer and Immutable.js can help enforce immutability at scale.

Declarative Array Methods

Functional programming favors declarative constructs that describe what should happen rather than how it should be done. JavaScript’s array methods support this approach.

Examples:

const numbers = [1, 2, 3, 4];

const squared = numbers.map(n => n ** 2);
const evens = numbers.filter(n => n % 2 === 0);
const sum = numbers.reduce((acc, n) => acc + n, 0);

These methods abstract away the control flow, resulting in concise and readable code.

Point-Free Style

Point-free style, also known as tacit programming, involves writing functions without explicitly referencing their arguments.

Example:

const toUpper = str => str.toUpperCase();
const exclaim = str => str + '!';

const shout = compose(exclaim, toUpper);
shout('hello'); // "HELLO!"

While point-free style can enhance composability, it should be used judiciously to maintain readability.

Libraries and Tools

To facilitate functional programming in JavaScript, several libraries provide utility functions and data structures:

Ramda – A utility library designed specifically for functional programming
Lodash/fp – A functional wrapper of Lodash with auto-curried and immutable methods
RxJS – A library for reactive programming using observables
Immutable.js – Provides persistent immutable data structures

These tools can greatly simplify the implementation of functional patterns in large applications.

Practical Example: Data Transformation Pipeline

Consider the task of transforming user data using functional techniques:

const users = [
  { name: 'Toni', age: 30 },
  { name: 'Ana', age: 17 },
  { name: 'Leo', age: 22 },
];

const isAdult = user => user.age >= 18;
const getName = user => user.name;
const toUpper = str => str.toUpperCase();

const adultNamesUpper = users
  .filter(isAdult)
  .map(getName)
  .map(toUpper);

// Result: ['TONI', 'LEO']

This declarative pipeline is concise, expressive, and easy to modify or extend.

Conclusion

Functional programming patterns offer a powerful way to write clean, modular, and maintainable code in JavaScript. By leveraging pure functions, composition, higher-order functions, and immutability, developers can create applications that are more robust and easier to reason about.

Incorporating these patterns into everyday development can lead to significant improvements in code quality and team productivity.

For developers looking to scale their applications or reduce complexity, adopting a functional mindset is a valuable investment.

Dao of Functional Programming (Chapter 1: Clean State)

Sat, 17 May 2025 20:57:34 +0000

This would be an irregular series of posts on my new attempt to learn Category Theory. This time, it would be based on the book titled The Dao of Functional Programming written by Dr. Bartosz Milewski. Currently, I am doing it with assistance of NoteBookLM to understand the material better. So let’s start with the first chapter today and answer the question — What are objects and arrows in the world of category theory?

An illustration generated by Copilot

The current attempt is likely my third or fourth time learning category theory myself. In my previous attempts, I usually got lost in the later chapters. Hopefully, with the help of NotebookLM playing the role as a tutor, things get easier.

Ah, how things have changed.

Articles in the series would mostly be unstructured, there would be a very minimal amount of effort in storytelling ..) Treat this as my study notes, and I welcome all feedback, insights, corrections etc.

Notation

Due to the limitation of Medium’s editor, for Mathematical symbols involving subscripts, say x ** 2 in Python, it would be written as x^2. In contrast, a subscript, would be written as x_2.

Types and Functions

The text advised against associating the concept of type and functions to concrete programming implementation. Therefore, please read the remainder of this article with a clean state of mind (now I understand the rationale behind the chapter’s name).

In the context of category theory, a type can be considered as an object or a proposition.
We can then assign names to each of them, e.g. a, b, c, or even familiar ones like Int, Bool, Double etc.
The names are assigned purely to differentiate them from each other whenever applicable.
The relationship between types, instead of what it is, is more essential.
A relationship is established by connecting the types with arrows.
Each arrow connects one source and one target type.
A special case to consider is that the arrow can loop around, forming a connection with the type itself.
Depending on the context or field of study, the arrows are named differently. We have been talking about types so far, so in this setting an arrow connecting types is called a function.
When used in the context of category theory, an arrow connecting objects is called a morphism.
In the world of logic, an arrow connecting propositions is called an entailment.
A proposition is something that may be true.
An implication is usually established with one premise mapping to an outcome or conclusion. The author uses the example “if wishes were horses, beggars would ride”. In this case, “wishes were horses” is the premise, and “beggars would ride” is the outcome. In this case, both premise and outcome are two different kinds of propositions. The implication, written in arrow form (wishes = horses) -> (beggars would ride), is therefore an entailment.
The names of arrows can be used interchangeably, but the core idea is that they establish connections.
Like what we did for types, we name arrows to differentiate them, as they may be more than one arrow between two types (objects, propositions).

In this case, the arrow can be interpreted as a function f mapping values of type a to type b.
Alternatively, it could also mean f is a proof that if a is true then b is also true.

Yin and Yang

I suppose types, and the corresponding functions, are considered as a specialized application of category theory. Each corresponding to a specialized object, and morphism respectively.

We define objects by their connections
An arrow is a proof/witness of the connection
If there’s no arrow, there’s no proof, therefore the objects are considered disconnected.
It is possible to have multiple arrows, hence many proofs.
Sometimes there’s a single proof — a unique arrow
Unique: even if we manage to find two arrows, they must be identical

Initial Object

An object with a unique outgoing arrow to every object, including itself.
Unlike an initial node in a graph, an initial object can have incoming arrows, but in the context of the categories covered (types, logic), we are assuming no incoming arrow for initial objects.
In Mathematics, often denoted by 0
The arrow from 0 to any object a is denoted by ¡ (or specifically ¡_a).
Can be seen as a source of everything.
As a type in Haskell, it is the Void type.
As an initial type, there is also an arrow (function) from Void to itself. Hence, it can derive Void and everything else. All the unique outgoing arrows (functions) are all called absurd.
In logic, it signifies logical falsehood/contradiction/counterfactual, written as F, False or ⊥.
Again, the outgoing arrow characteristic means we can establish any entailment (proving) starting from false premises. ⊥ -> a, for every proposition a
The earlier implication “If wishes were horses, beggars would ride” shows that, even the premise “wishes were horses” is false, but the arrow pointing to the proposition “beggars would ride” can still be drawn.

Terminal Object

An object with a unique incoming arrow from every object
Unlike a terminal node in a graph in a graph, a terminal object can have outgoing arrows.
In Mathematics, often denoted by 1
The arrow from any object a to 1 is denoted by ! (or specifically !_a).
Can be seen as an object that unites everything.
As a type in Haskell, it is the Unit type, denoted by ().
In logic, it signifies the ultimate truth, written as T, True or ⊤.
The incoming arrow characteristic means any proposition can entail True, regardless what they are. a -> ⊤, for every proposition a

| Category theory | Haskell | Logic |
|-------------------|----------|-------------|
| object | type | proposition |
| morphism | function | entailment |
| initial object, 0 | Void | ⊥ |
| terminal object | () | ⊤ |

Elements

Structure

Objects are primitive and cannot be broken down into smaller components
Structure: arrows pointing at the object (incoming arrows)
We can probe an object with arrows.
Assumption: For programming and logic, we want our initial object to have no structure, therefore no incoming arrow (aside from the self-looping arrow).
Void and False therefore have no structure.
Terminal object has only one way of probing it from any direction into the object, hence having the simplest structure.
Considered as the indivisible point: a single, uniform target reached by a unique connection from anywhere
Only property is that it exists, proved by the existence arrow from any other object (recall proof: having an arrow connecting objects).

Probing other objects

Terminal object is simple, can use it to probe other more complex objects
If there are more than one arrow from the terminal object to an object a, then a has some structure.
Each arrow means a way to look at an object, having multiple arrows means more than a way of looking at it.
Now we know a terminal project behaves like a (indivisible) point, can visualize each arrow from it as picking another point or element of its target (another object)

Global Element

As mentioned previously, initial object can have incoming arrows. However, in the context of the Cartesian closed categories covered, incoming arrows are not allowed.

The arrow x is defined as a (global) element of_ _a.
The notation in type theory: x : A, x is of type A
The Haskell counterpart (use double colon notation): x :: A
Haskell uses capitalized names for concrete types such as Void, Int, Double etc. In the example, it is A
Lowercased names for type variable, in the example it is x
The example defined x as a term of type A
Categorically, we interpret it as an arrow x : 1 -> A, which is a global element of A
In logic, x is the proof of A because it corresponds to the implication (a type of entailment, or an arrow) T -> A (if T is true then A is true)
There may be multiple proofs of A (many arrows from T to A)
Initial object like Void has no incoming arrow including from the Terminal, therefore Void has no elements.
Void is therefore considered empty.
Terminal object has only one unique arrow coming from itself 1 -> 1
Due to the unique self-pointing arrow, it is sometimes called a singleton

The Object of Arrows

Arrows between two objects form a set (with some exceptions, but I am ignoring that for now)
In programming we talk about the type of functions from a to b, in Haskell it would be f :: a -> b
Side note: In Python it would be f: Callable[[a], [b]]
Meaning: f is of the type “function from a to b” (a -> b)
So if a -> b is a type, then there would be an object that represents the set of arrows (functions) from a to b.
Further steps to define this object of arrows to be covered in later chapters.
In addition to the set of arrows, there is an object of arrows.
Recall, an element of an object is defined as an arrow from a terminal object (Unit) to a target object.
Therefore, in this case, an element of the object b^a is an arrow from the terminal object to b^a, and this arrow corresponds to a function of type a -> b
In category theory, the object of arrows is called an exponential, and is written as b^a (source object in the exponent)
Therefore f :: a -> b, written as an element of an object of arrows is as shown below.

One thing to note is that if there is no arrow connecting a and b, then the set of arrow a -> b is empty, and we will fail to find the global element arrow (prove) between the terminal object and corresponding b^a object.
For example, in programming, if there is no way to map an Int to Bool, then the set of the function Int -> Bool is empty, and there will be no elements in the corresponding Int^Bool object.
In logic, an arrow A -> B is an implication, it states the fact that “if A then B”.
Therefore, the exponential object B^A, is a proposition in the context of the following expression:

Recall in logic T -> A means if T is true, then the proposition A is True.
Also recall an arrow is a proof where two objects are connected.
So the global element x means the entailment from A to B exists, and is also valid.
Therefore when we revisit the statement “If wishes were horses, beggars would ride” as a proposition (an object), then we should be able to prove the arrow from A (wishes were horses) to B (beggars would ride).
However, in the case where “wishes = horses” cannot be proven as there is no arrow from the ultimate truth to the proposition. Therefore, the original implication is valid, but the premise cannot be found, hence beggars would not ride.

Closing thoughts

Understanding the object of arrows in the context of logic takes up a lot more time than I initially expected, but I am quite happy I finally managed to complete the article. One piece of advice I would share is try to learn as if you have not done much Mathematics before. Prior knowledge in other fields has only brought confusion so far. Anyway as this is going to be irregular, I will continue when I have the time.

This article was written with assistance from Gemini, a large language model by Google. Gemini provided editorial help, fixing language errors and checking for article flow. If you’d like to collaborate or discuss job opportunities, please connect with me on LinkedIn or via Medium.