From Types to Arrows: A Gentle Introduction

“Everything is connected.” — Cloud Atlas (2012)

When I first learned category theory, it felt like discovering a secret map underneath programming. It’s not about memorizing symbols — it’s about seeing connections, patterns, and journeys between things. Let’s explore this world using Kotlin and human-friendly analogies.

Objects (Types)

Definition (Category Theory):

Objects are the fundamental entities in a category. They don’t do anything on their own; they just exist and provide structure.

In Kotlin:

Objects correspond to types — for example, Int, String, Boolean, List<T>, or even custom classes like data class User(val name: String, val age: Int).

val name: String = "Arun"
val age: Int = 28
val scores: List<Int> = listOf(10, 20, 30)

Expanded Explanation:

• Every object defines a domain for functions (arrows) to act upon.

• Objects are containers of values — they describe what kind of data can exist.

• You can think of them as “stations” or “cities”: they hold information, but the magic happens when you connect them via arrows (functions).

Analogy for Beginners:

1. Cities on a Map:

• Each type is a city. Int city has numbers, String city has letters and words.

• You can visit these cities (create values), but to move information between cities, you need roads (functions).

2. Boxes:

• Each object is a box. You can store something inside it, but the box itself doesn’t do anything. Only when you pass it to a function (arrow) does action happen.

3. Real-Life Example:

• List<String> is like a basket of fruits. The basket itself is the type (object), but the fruits (values) inside can be transformed, sorted, or filtered using functions.

Morphisms (Functions as Arrows)

Definition (Category Theory):

A morphism is an arrow that connects two objects. It represents a relationship or transformation from one object to another. Every morphism has a source (starting object) and a target (ending object).

In Kotlin:

A morphism is any function that takes a value of one type and returns a value of another type (or the same type).

fun toUpper(s: String): String = s.uppercase() // String -> String
fun lengthOfString(s: String): Int = s.length   // String -> Int
fun isEven(n: Int): Boolean = n % 2 == 0       // Int -> Boolean

Expanded Explanation:

• Morphisms are actions that move or transform values between types.

• They are directional: you cannot use them backwards unless explicitly inverted

• They are pure descriptions of how one type relates to another — like a blueprint of a road connecting two cities

Analogy for Beginners:

1. Roads Between Cities:

• Types are cities. Functions are roads connecting these cities.

• String -> Int is a road where a word is turned into a number (its length).

2. Conveyor Belt:

• Imagine a factory conveyor belt: you put an item (value of type A) at the start, it passes through a machine (function), and comes out transformed (value of type B).

3. Recipe Analogy:

• The function is a recipe: input ingredients (values) go in, the recipe (function) is applied, and the final dish (output) comes out.

• Example: lengthOfString("Kotlin") → 6

“The journey is just as important as the destination.” — Every function ever

Composition of Functions

Definition (Category Theory)

In Category Theory, composition is the rule that allows two morphisms to combine and form a new one.

Formally: If

f : A → B  
g : B → C

then their composition is

g ∘ f : A → C

That means — first apply f, then g.

Composition is associative, and every object has an identity morphism that doesn’t change the result when composed.

In Kotlin

fun trim(input: String): String = input.trim()
fun toUpper(input: String): String = input.uppercase()

// Manual composition
fun process(input: String): String = toUpper(trim(input))

println(process("  arun  ")) // Output: ARUN

Or functionally:

infix fun <A, B, C> ((A) -> B).andThen(g: (B) -> C): (A) -> C = { a -> g(this(a)) }

val process = ::trim andThen ::toUpper
println(process("  lambda  ")) // Output: LAMBDA

Expanded Explanation:

Composition is like chaining transformations.

Each function focuses on one task — trim cleans the input, toUpper transforms it.

By composing, you create a data flow:

input → clean → transform → result.

You don’t mutate the input; instead, you pipe data through pure functions.

This makes the code more modular, reusable, and testable — the essence of FP.

Analogy: Lego Blocks

Think of each function as a Lego block.

One shapes the piece, another colors it.

Alone, they do small jobs — but when snapped together, they build something new.

That’s function composition — small, reusable pieces combining to form powerful results.

“Big programs grow from small ones by composition.” — John Backus (Inventor of FP concepts)

Identity Morphism → The Mirror That Changes Nothing

Definition(Category Theory):

For every object A in a category, there exists a morphism

such that for any morphism f : A → B:

In simpler words — an identity morphism is a function that, when composed with others, doesn’t change their behavior. It’s like pressing the “refresh” button but nothing actually changes — it just confirms the system still works.

In Kotlin example:

fun <T> identity(x: T): T = x

val value = 42
println(identity(value)) // Output: 42

// Composition with identity
val double: (Int) -> Int = { it * 2 }
val composed = double.compose(::identity)
println(composed(5)) // Output: 10

Here, the identity function doesn’t modify the data — it simply returns it. When used in composition, it behaves like a neutral element, much like 0 in addition or 1 in multiplication.

Analogy: The Perfect Mirror

The identity morphism is that mirror in the world of functions. Whatever you give it, it gives back unchanged.

“Sometimes doing nothing is the most powerful thing you can do — especially when it keeps the system consistent.”

Expanded Explanation:

The identity morphism ensures structural consistency within a category. It acts as the “glue” that guarantees composition behaves properly.

Every object (or type) in your system needs its own id to say:

“I can map myself to myself without losing meaning.”

This is foundational to Category Theory — without identity morphisms, you can’t define a valid category!

Wrapping Up

We’ve taken our first gentle steps into the world of Category Theory — not as mathematicians, but as curious developers trying to see the bigger picture behind functions, types, and composition.

We started with simple objects (types like Int, String), connected them with morphisms (functions as arrows), learned how these arrows compose, and finally met the humble identity morphism, the function that changes nothing yet means everything.

If all this still feels abstract — that’s perfectly fine. Category Theory is like learning to see code from a higher altitude — at first, things look blurry, but soon the patterns become beautiful and natural.

As the proverb goes:

“The beginning of wisdom is calling things by their right names.”

Now, you know the names — objects, morphisms, composition, and identity. In the next blog, we’ll go a bit deeper and explore how these ideas evolve into functors and mappings between categories — the real bridge between mathematics and programming.

Until then, keep composing functions, stay curious, and remember:

Every big abstraction starts with a small arrow.