Types & Functions — The Real Building Blocks of Programs

Types tell you what something is. Functions tell you what it can do.

Before we talk about category theory and FP, we must get two things perfectly clear:

• What are types?

• What are functions?

Let’s walk through them like a story.

The Typing Monkeys Story

Imagine millions of monkeys sitting in front of computers, banging on keyboards, trying to accidentally write a valid program.

• In machine code, any random bytes are “valid,” so monkeys are happy — everything runs.

• In dynamically typed languages, the program may run… until it suddenly crashes because someone added a number to a banana.

• In statically and strongly typed languages, most monkey-written programs don’t even compile

That sounds cruel… but here’s the twist:

Fewer happy monkeys → More correct programs

Typing is like having:

• A grammar checker

• A spell-checker

• A logical consistency checker (type checker)

All working together before the program even runs.

If Romeo is declared a human, he shouldn’t grow wings or become a black hole halfway through the story

Types stop nonsense early.

Why Do We Need Mathematical Models for Programming?

Because programs are compositions of pieces, just like:

• Lego blocks

• Electrical circuits

• Water pipes

But compositions only work if the ends match.

In category theory:

You can only compose arrow f: A → B with arrow g: B → C because B matches B.

In programming:

You can only pass output of function f into function g if f returns the type g expects.

Types ensure the ends match.

Without types, you’re mixing pipes of different diameters and hoping nothing explodes.

What Are Types (Really)?

Here’s the clean mathematical idea:

A Type = A collection of possible values + the rules that apply to them.

For example:

Int   → {… −2, −1, 0, 1, 2 …}
String → {"hello", "world", "…"}
Boolean → {true, false}

A type tells you:

• What operations are allowed

• What values are valid

• What functions can accept it

• How two parts of a program can fit like puzzle pieces

Weak vs. Strong Typing

• Weak typing lets you mix things freely.("5" + 2 == "52" in JavaScript)

• Strong typing forces you to be explicit. No accidental merging of bananas and booleans.

Simple Analogy

Weak typing → A kitchen where all bottles look the same

Strong typing → Bottles are clearly labeled: “salt,” “vinegar,” “oil”

Which kitchen produces better food?

Static vs. Dynamic Typing

• Dynamic typing: errors appear when running the program

• Static typing: errors appear before running

Analogy:

• Dynamic typing = discovering the airplane has a missing bolt while flying

• Static typing = discovering it in the hangar

Which one is safer?

What Are Functions?

This is the heart of FP.

A Function = A machine that takes input and gives output

Mathematically:

A function is a mapping from values of one type to values of another type.

f: A → B

In Kotlin:

val length: (String) -> Int = { it.length }

Functions:

• Take something of type A

• Produce something of type B

• Must not mutate the input

• Always return the same output for the same input (purity)

Functions as Arrows (Category Theory POV)

In category theory:

• Objects → Types

• Arrows → Functions

• Composition → Piping outputs into inputs

A --f--> B --g--> C

Becomes:

val f: (A) -> B
val g: (B) -> C
val h = g compose f

Why Functions Matter: They Make Composition Possible

Composition only works if:

• The output type of f matches the input type of g

• Types ensure correctness

• Functions ensure transformation

• Together they form composable systems

This is why FP loves functions and types:

They allow you to break big chaos into small perfect transformations.

Think of it like running a small café.

Each person in your kitchen has one job:

• One chef cuts vegetables

• Another cooks them

• Another plates the dish

Each station expects a specific kind of input.

The chopping chef can only handle raw vegetables, not fully cooked food.

The cooking chef expects chopped vegetables, not whole carrots.

The plating chef expects cooked food, not raw ingredients.

If any step receives the wrong kind of input, the whole workflow falls apart.

Functions work exactly the same way.

• A function takes a specific “ingredient” (type).

• It transforms it into a new “dish” (another type).

• Only when the dish matches the next chef’s expectation can it move forward.

That’s why FP cares so much about types and functions:

They turn a messy kitchen into a perfect assembly line, where every step is safe, predictable, and composable — and where you can swap out or improve one step without breaking everything else.

Functions and types are the backbone of composition. Types make sure every step receives the right kind of input, and functions transform that input into the next meaningful output. This simple discipline — the right thing in, the right thing out — turns complex systems into predictable, composable flows. Just like an ATM works by chaining small steps, functional programs work by connecting small, reliable transformations.

In the next post, we’ll go one level deeper and explore Function Signatures and Pure Functions. You’ll learn how signatures describe the behavior of functions even before writing code, why purity matters for reliability, and how real-world systems benefit from deterministic functions. This sets the stage for understanding higher-order functions and more advanced composition patterns.