So, I wrote a book on High Order Functions

In one sentence: I wrote a book on higher order functions, I will have it in print in August, and there is an 80% chance I will never write another one.

The book is called Applied Higher Order Functions: A Functional Architecture of Optimization, Decision Making, and Validation.

I am self-publishing it.

In August, I should have real, physical books. Hardcover, beige cloth, orange foil on the cover. I will give some of them to attendees at Lambda World in Málaga and at Clojure/conj later this year.

Honestly, this still sounds quite strange to me.

Why this book?

There are many books on functional programming. And there are many books about algorithms. But I wanted to connect these two things in a way I haven’t seen before.

The basic idea is simple.

A gradient descent optimizer and a value iteration solver are doing the same thing. They take a state and repeatedly improve it until they converge.

A genetic algorithm and a particle filter are also doing the same thing. They keep a population, evaluate it, and create a new population.

Q-learning takes observations one by one and updates a model. That’s a fold.

The mathematics is different. The terminology is different. People who study these things often belong to completely different fields. But the computational structure is the same.

This is what higher order functions make visible.

Higher order functions are not map and filter

When someone explains higher order functions, he usually starts with map, filter, and reduce.

There is nothing wrong with that. But I think it makes the whole topic look smaller than it really is.

A higher order function is a function that takes another function, returns a function, or both. This definition is short. Almost disappointingly short.

But if you take it seriously, a higher order function can represent the architecture of a whole family of algorithms.

For example, you can separate an iterative algorithm into a step function, a stopping condition, and the mechanism that repeats the step. Change the step function and gradient descent becomes Newton’s method, Adam, or value iteration. The outside structure stays the same.

This isn’t just shorter code. It tells us which parts of algorithms are actually different.

Seven patterns

I went through hundreds of algorithms from optimization, decision making, validation, and machine learning.

The catalog behind the book contains roughly 480 of them.

And most of their structures can be described with seven patterns:

• Iterate is the engine of search. It repeatedly applies a step function.
• Fold is the engine of learning. It updates a model from incoming observations.
• Population evaluates, selects, recombines, and mutates candidates.
• Generate-and-Test creates candidates and accepts or rejects them.
• Tree Search explores branching possibilities.
• Compose joins multiple stages into a pipeline.
• Transform takes a function and returns a changed function.

Of course, this doesn’t mean 480 algorithms are all the same.

But when you remove the notation and domain-specific words, there is much more repetition than it looks like. The interesting differences are often in the functions passed into the structure: the update rule, objective function, evaluation strategy, stopping condition, mutation, or policy.

Once you see this, it is hard to unsee.

Why Clojure?

All code in the book is Clojure.

This was an obvious choice for me. In Clojure, functions are normal values. There is almost no ceremony around passing them, returning them, or composing them. The language doesn’t fight the idea of the book.

It also means that the code can look very close to the structure I am describing.

The book starts with foundations, then goes into optimization, decision making, and validation. There are chapters about population methods, descent, constraints, Bellman operators, online learning, Monte Carlo tree search, temporal logic, falsification, and reachability.

There are sixteen chapters, five parts, and three appendices.

I also made orhof, a companion Clojure library. All listings run against it. I didn’t want to write pseudocode that only looks correct in a printed book.

And this created a lot more work.

It was intensive

Writing the text was only a part of writing the book.

There were hundreds of code listings. They had to compile and return the results claimed in the text. Equations had to agree with code. Diagrams had to agree with both. Then references, index, layout, typography, print profiles, colour pages, margins, and cover.

At some point, we found listings that looked correct but diverged. An example had an output that the code couldn’t produce. An API reference no longer matched the library. A diagram used different numbers than an equation.

Many such cases!

Every correction could lead to another correction somewhere else.

It was a very intensive period. I spent a huge amount of time on the book. Even when I wasn’t writing, I was thinking about chapter structure, examples, an incorrect function signature, or some sentence that didn’t say exactly what I wanted it to say.

Writing a technical book is a good test of whether you understand the topic.

It is also a good test of how long you can continue looking at the same topic.

Was it worth it?

I didn’t write it for money.

Technical books are probably not the best way to make money anyway. Especially a self-published technical book about higher order functions in Clojure.

I wanted the book to exist. I wanted to explain the idea. I wanted to make a physical thing that is mine, from the argument and code to the paper and cover.

But honestly, I am not sure if the time was worth that.

Right now, I think there is an 80% chance I will not write another book.

Maybe this will change when I hold it in my hands. Maybe someone at Lambda World will read it, send me a message, and tell me that the book changed how he thinks about algorithms. That would move the calculation a bit.

But books are romantic from a distance. When you are writing one, a lot of the work isn’t romantic at all. It is going through another code listing. Fixing a page break. Checking whether a mathematical claim is too broad. Rebuilding the PDF. Finding one more error after you thought you were done.

I am happy that I did it.

I am not sure I want to do it again.

Why self-publish?

Self-publishing gives me control over everything.

That is both the reason to do it and the reason not to do it.

The book is typeset for a 170 × 250 mm hardcover. Most pages print in black, with a few colour diagram pages. The diagrams are vectors. The cover has a lambda motif, orange foil, and beige cloth.

I care about those things. A useful technical book doesn’t need to be ugly.

The manuscript is licensed under Creative Commons Attribution-ShareAlike 4.0. The companion library uses the MIT License. So people don’t have to buy the hardcover to access the ideas. Buying it means getting the physical edition.

This seems fair to me.

Knowledge should be accessible. And a book should be a nice object.

What happens in August?

In August 2026, boxes of books should arrive.

Then I will take some of them to Lambda World in Málaga. Later, I will take some to Clojure/conj. I will give them to people who are interested enough in functional programming to attend a conference about it.

That feels like the right place for them.

The main claim of the book is that optimization, decision making, and validation are not hundreds of unrelated recipes. Many of them are compositions of the same small family of higher order function patterns.

The definition of a higher order function fits into one sentence.

For some reason, I needed a whole book.