# Layman's Guide to Higher-Order Functions

An introduction to higher-order functions I wish I've had in school.

By Niko Heikkilä / September 27, 2022 / ☕️ 4 minutes read

The single most important topic in functional programming is to understand what a function is. Inherently, a function is a way to map the input value of some type to output value of another type. To put it in other words, you give your function a problem, and it returns a solution.

In mathematics, you may have stumbled upon the formal definition of a function: $f: A \to B$

This is essentially the same as written above. We define a function $f(A)$ accepting a value of type $A$ and returning a value of type $B$. Note that both $A$ and $B$ could be of the same type, but for the sake of this example, we keep them separate.

In programming, problems are bound to grow more difficult over time, and thus solutions grow more complex. Typically, the larger the problem, the larger our function grows in size. Following the principles of clean code — single-responsibility principle, to be accurate — we need to keep in mind that functions should have only one reason to change. Thus, we should split our logic to small cognitively easy pieces.

So, what possibly could help us? Adding more functions!

When solving a large problem, the important approach is to divide and conquer. First, break the problem into small parts (divide) and then solve each of them one by one (conquer). We can use the concept of higher-order functions to achieve this.

## Anatomy of a Higher-Order Function

A higher-order function is defined to have either of the following two properties:

1. It takes one or more functions as its arguments
2. It returns another function (a closure)

React developers know that for example, the React.useState hook for managing component state is a higher-order function since it returns a function used for updating the state.

TypeScript1const App = () => {
2    const [counter, setCounter] = useState<number>(0);
3    // typeof setCounter === 'function'
4};

At first, higher-order functions seemed to me like an overcomplicated problem-solving tool. Why not write a single function and call other functions from inside? Truthfully speaking, I thought as much about object-oriented programming before grasping how different design patterns improve the code.

This was my mind before I understood the value of declarative programming over imperative. In declarative programming, you define what things are, whereas, in imperative programming, you define what things do.

Solving problems in a declarative way is a perfect demonstration of divide and conquer. Let's take an example.

Assume we are given a user password for validation. Our function should return true if the password is valid, and false otherwise. We have received the following requirements for validating passwords:

• password must contain 12 or more characters
• password must contain at least one uppercase and one lowercase character
• password must contain at least one number

What an easy task, you might think. Write a function with a couple of conditional blocks and after having run through all of them return the intended result. Let's grab a keyboard and start defining our function.

Haskell1validate password
2    | not (longEnough password)     = false
3    | not (hasUpperCase password)   = false
4    | not (hasLowerCase password)   = false
5    | not (hasNumbers password)     = false
6    | otherwise                     = true

This is perfectly fine for a lax validation. However, what if requirements keep on coming, and you need to add more and more conditionals into your function? Your function could quickly grow to a convoluted, unmaintainable, and unreadable mess.

One solution is to define each validator as a function and pass it as an argument. The example below is in TypeScript.

TypeScript1/** Helper for chaining and printing the validator warnings **/
2const warn = (msg: string): boolean => {
3    console.warn("Invalid:", msg);
4    return false;
5};
6
7type Validator = (password: string) => boolean;
8
9const longEnough = (password: string, minLength = 12) =>
11    warn(Password should contain \${minLength} or more characters.);
12
13const hasUpperCase = (password: string) =>
15    warn("Password should have at least one uppercase letter.");
16
17const hasLowerCase = (password: string) =>
19    warn("Password should have at least one lowercase letter.");
20
21const hasNumbers = (password: string) =>
23    warn("Password should have at least one number.");
24
25const validator =
26    (...fns: Validator[]) =>
29
31    longEnough,
32    hasUpperCase,
33    hasLowerCase,
34    hasNumbers
35);
36
42
44// Valid passwords are: ['Passwordpassword1']

Breaking this down you can see that longEnough, hasUpperCase, hasLowerCase, and hasNumbers are each a closure passed to the validator function. Using variadic arguments — known as the spread operator (...) in JavaScript — we can pass any number of validators and our code takes care of the rest.

The Array.prototype.every() function returns true if the array satisfies all the conditions passed so here we pass predicate (boolean) functions as conditions.

Another sweet aspect of higher-order functions is the ability to curry your functions. Here we pass our password to the isValidPassword function, which itself is built on from curried functions. Doing this, we don't have to define the validation rules again each time we wish to validate a given password. This makes the code easier to read again.

Perhaps your head is spinning fast right now, so let's write the validate function without the ES6 arrow notation to examine it further.

TypeScript1function validator(...fns: Validator[]) {
3        return fns.every(function(fn) {
7};
After removing the arrows, we have a function satisfying both pre-conditions of being a higher-order function. In my opinion, arrow functions have made writing especially JavaScript way more succinct since we can write all of this in one line and without using a single return statement. No more nested code, also known as hadouken code.