From Nothing to Arrows: Objects and Simple Graphs

“Every complex system that works evolved from a simple system that worked.” — John Gall

Category theory doesn’t begin with abstractions or equations. It begins much like programming itself: with nothing… and then with arrows.

Before we talk about fancy ideas like functors or monads, we need to understand how structure is born.

A Small Story: Starting from Nothing

Imagine opening a brand-new Kotlin project for the first time.

No files. No classes. No functions.

Just a silent editor and a blinking cursor.

At first, it feels useless — there’s nothing to run, nothing to test, nothing to debug. And yet, that emptiness is not chaos. It’s valid. The compiler isn’t confused. The IDE isn’t broken. The project exists, even though it does nothing.

That “nothing” is not an error — it’s a starting point.

In Kotlin, and in good system design in general, emptiness is often intentional. It represents a state where nothing can happen yet, but also nothing can go wrong. No invalid states, no surprises, no side effects. Just a clean, well-defined beginning.

This is the same idea behind Kotlin’s Nothing type and category theory’s empty category: a space with no values, no paths, and no behavior — yet one that fits perfectly into the system’s rules.

Before we build arrows, before we compose functions, before we move data around, we begin here — with nothing. And from that quiet place, structure emerges.

1. No Objects — When Nothing Is Still Valid

In category theory, there exists something called the empty category.

It has:

At first, this sounds useless. But as programmers, we already rely on this idea every day.

Kotlin already understands “nothing”

val users = emptyList<User>()

This list:

It’s not an error — it’s a base case.

Kotlin even has a type that represents impossibility:

fun fail(message: String): Nothing =
    throw IllegalStateException(message)

Nothing has:

The empty category plays the same role:

It exists so the system is complete, not because it does something.

Why category theory allows this

Category laws say:

If there are no objects, there is:

All rules are satisfied vacuously.

Just like an empty loop:

for (x in emptyList<Int>()) {
    // never runs, never breaks
}

2. Simple Graphs — When Structure Appears

Now let’s add just a little something.

Imagine this:

A → B → C

This is a directed graph:

At this stage, it’s not yet a category. It’s just potential.

How a Graph Becomes a Category (Naturally)

Category theory doesn’t ask you to invent new behavior. It asks you to accept what is unavoidable.

Step 1: Identity — “Stay where you are”

Every object must be able to do nothing.

So we add:

A → A
B → B
C → C

In Kotlin, this is the identity function:

fun <T> id(value: T): T = value

You almost never write it — but it’s always there.

Step 2: Composition — “If it chains, it exists”

If you can go from:

A → B
B → C

Then you must allow:

A → C

This arrow represents doing both steps in sequence.

In Kotlin, this is just function composition:

fun <A, B, C> compose(
    f: (A) -> B,
    g: (B) -> C
): (A) -> C = { a -> g(f(a)) }

A Kotlin story (very real)

fun parse(input: String): Int = input.length
fun validate(n: Int): Boolean = n > 3
fun render(ok: Boolean): String =
    if (ok) "Valid" else "Invalid"

You didn’t plan a pipeline upfront — but Kotlin allows this:

val pipeline =
    compose(
        compose(::parse, ::validate),
        ::render
    )

That pipeline emerged.

This is exactly what category theory calls a free category.

What “Free Category” Actually Means

A free category is just a way of not forgetting anything. Imagine a map with places and roads. Every place becomes an object, every road becomes a connection, and every possible route you can travel is remembered. Staying where you are also counts as a route — that’s the identity. If you can go from A to B and then from B to C, the system simply accepts that A to C is a valid path too. Nothing clever is happening; it’s just acknowledging what’s already possible.

What makes it “free” is that no extra rules are added on top. No shortcuts are assumed, no paths are merged, and no optimizations are made. If there are ten different ways to reach the same destination, all ten are kept. A free category doesn’t try to decide which path is better or faster — it only records the structure of how things can be connected. It’s the most honest starting point: everything that can be composed exists, and nothing more is assumed.