It seems like the general consensus among JS programmers is that for processing collections of data higher order functions are king. No longer does one have to wade through many nested `for` loops in order to process an array, mutating it along the way, accessing individual elements with cryptically named `i`s and `j`s and spending an hour trying to figure out what exactly happens inside a three-nested loop code block.

For most situations using array methods, such as `.map`, `.filter`, `.sort` and `.reduce`, is much easier. Not only to write, but also to convey the intent of what is meant in a more concise and understandable way. While it may take one a while to process a `for` loop which only doubles all the numbers in an array, with the use of `.map` it can simply be written as `array.map(x => x * 2*)`.

However, when faced with slightly more complex problems, it might not be immediately apparent what array method would be most appropriate for a given task. While one learns rather quickly that "`.map` takes an array, and returns an array with each element of the original array ran through the iteratee." That's quite a mouthful, and keeping all of that in mind when thinking about a solution to a problem is not that easy, especially since at first one tends to recoil and jump back to the more familiar imperative mode of thinking with loops and indices.

What in my opinion is most instructive is to think about each array method in terms of the lengths of the input and output arrays and how they change depending on which method is used. That way one first thinks about _what_ is to be done to the collection and then _how_ it is to be done.

# Fixed-length methods

The first category of array methods are those which do not change the length of the input array - `.map` and `.sort`.

```javascript
const numbers = [1, 2, 3]
const doubledNumbers = numbers.map(x => x * 2) // [2, 4, 6]
```

Mapping an array to something else is certainly one of the most common ways to process collections. In React, it is used to map data from the application state into elements of the UI. Using `.map` allows for dividing the problem of processing an array into two distinct steps. First, we recognise that each element must be processed individually. Then, we specify how to do it, having to think only about one element at a time.

```javascript
const users = [
	{ name: 'Anna', surname: 'Komnene' },
	{ name: 'Michael', surname: 'Psellos' },
	// ...
]
```

Let's say you want to join the names of the users into a single string. Well - how would you join the names of one user?

```javascript
const joinName = user => `${user.name} ${user.surname}`
```

The only thing that's left is applying the function to each element of the `users` array via `.map`:

```javascript
const usernames = users.map(joinName)
```

When reading code, `.map` gives us some guarantees. We do not have to delve into the iteratee to be guaranteed that the elements are not in a different order, or that the length of the output array is different than the input. The only thing that has changed are the values of the elements of the input array.

`.sort` is similarly straightforward, and here, too, we can say with certainty that the length of the array has not been changed. In this case we also know that the values are the same and the only thing that's been impacted is the order. The only larger trouble with `.sort` is having to remember the ternary state of the comparator function. Remembering that using `(a, b) => a - b` will result in numbers being sorted in an ascending order is usually enough to get to a solution.

```javascript
const numbers = [3, 1, 2]
const sortedNumbers = numbers.sort((a, b) => a - b) // [1, 2, 3]
```
# Aggregation methods

Next are the aggregation methods, which each produce a value from an ever narrower set of possibilities. `.filter` results in an array of equal or shorter length, `.find` (and its siblings, `.findLast`, `.findIndex` and `.findLastIndex`) comes up with just one item of the array, while `.some` and `.every` return a mere boolean value.

```javascript
const numbers = [1, 2, 3, 4, 5, 6]

const isEven = n => n % 2 === 0
const evenNumbers = numbers.filter(isEven) // [2, 4, 6]
const two = numbers.find(isEven) // 2
const hasEven = numbers.some(isEven) // true
const allEven = numbers.every(isEven) // false
```

Consider here that, especially with `.filter`, there also are certain guarantees - the output array will not have its individual values modified or their order changed, the only thing that can happen is that some will be missing.

# Dynamic-length methods

Finally, we have two most powerful methods which are not constrained by the size of the array. With `.flatMap` we might end up with more or less items, however we are guaranteed to end up with an array. This is not the case with `.reduce`, which collapses the entire collection to a single value (which, well, can also be an array that's even longer).

`.flatMap` especially is quite daunting at first glance - why exactly would we need to have it? The way it's often explained doesn't make sense either - it maps and then flattens, but why is that so important that we need to have a separate function for it in the JS spec?

The usefulness of `.flatMap` is that it gets around the limitation of `.map` being allowed to map one input element to exactly one output element. `.flatMap` can transform a single input element into zero, one, or more output elements. That way we can, for example, implement a filter in terms of `.flatMap`.

```javascript
const numbers = [1, 2, 3, 4, 5, 6]
const evenNumbers = numbers.flatMap(n => isEven(n) ? [n] : []) // [2, 4, 6]
```

What might be even more useful is that using `.flatMap` we can filter and map at the same time. An example - a validator that transforms a list of values into a list of errors.

```javascript
const numbers = [1, 2, 3, 4, 5, 6]
const errors = numbers.flatMap(n => !isEven(n)
	? [`${n} is not even.`]
	: []
)
// ['1 is not even', '3 is not even', '5 is not even']
```

In general, `.flatMap` will commonly work for problems to which one's first intuition is to reach for a mutable array, `.push` some items and then return it at the end.

The last array method, and the most powerful one, is also one whose use is often most discouraged. `.reduce` allows for collapsing an entire array to a single value. The value can be anything - a primitive value, or even something more robust like an array or an object. What's interesting is that we can reimplement pretty much every single other array method in terms of `.reduce`.

The way reduce works is that you supply it with a "reducer" function `(accumulator, value) => newAccumulator` which is repeatedly applied to the elements of the array, much like `.map`, however it also carries with it an accumulator argument. In many other languages a similar function is called `fold` which also illustrates its purpose.

```javascript
const numbers = [1, 2, 3]
const add = (a, b) => a + b
const sum = numbers.reduce(add, 0)
```

I said [before](monoids-in-practice), though it is worthy of a repeat, that in my view there are two main ways one can use `.reduce`. The reducer can take two values of the same type - in which case it exploits the monoidal nature of arrays, as above - or two values of different types, in which case it might be better to rewrite it first with a `.map`. An example of this can be a function converting an array to a map.

```javascript
const users = [
	{ id: 'abc', name: 'Anna', surname: 'Komnene' },
	{ id: 'def', name: 'Michael', surname: 'Psellos' },
	// ...
]

const usersMap = users.reduce(
	(map, { id, ...user }) => map.set(id, user),
	new Map()
) // Map{'abc' => {...}, 'def' => {...}, ...}
```

However, one can just as well do this in two steps:

```javascript
const usersEntries = users.map(({ id, ...user }) => [id, user])
const usersMap = new Map(usersEntries)
```

It is tempting to use the power of `.reduce` to write `for` loop-like constructs, but that's rarely a good idea.

# What next?

This way of thinking about array methods is actually a good way to learn about algebraic structures as well. After all, many of the array methods exploit the fact that arrays in JS implement certain algebraic structures. `.map` is an implementation of a functor's `fmap`, `.flatMap` is an implementation of a monad's `bind` and `.reduce` is an implementation of a monoid's `concat`. But even without knowing about the category theory behind arrays, it is useful to think about the array methods just in terms of the number of elements that they affect.


Understanding Array Methods

It’s becoming increasingly difficult to talk about the world with others. Sometimes it feels like the people we talk to inhabit completely different universes in which they perceive completely different truths through completely different lenses.

I’ve heard multiple explanations and multiple heuristics on how to approach this sorry state of affairs in order to not lose one’s sanity. One was to only say about what things are, and how one does something; refrain from saying how things should be and how one should do something. But that’s just kicking the can down the road: now, more than ever, we can’t agree on what things are.

That’s not particularly surprising, because most people seem to never think about how we actually perceive what things are. They simply assume that others see the world as they do for most of the time, and only do a double take when faced with a disagreement. I do not mean to make it seem like it’s a deficiency on anyone’s part — it’s actually fairly useful and understandable way of operating.

For most of history everyone was surrounded by those who were brought up and educated in the same way. And since most people used to have real things to do in the real world, the freedom not to have to think about how others perceived the world had a large degree of utility. If we can agree on the meanings of the fundamentals, we can be free to explore more complicated ideas and build more complicated structures, leaving the minutiae behind us. It’s easier to build a bridge when you don’t have to ask “what do you mean by…” every couple of minutes.

Many still operate under that assumption of common terms, even though it is evidently no longer true. Why?

# The analytic knife

Describing something is a very dangerous activity. Whenever one describes something, what is actually done is slicing up reality into distinct parts with a very sharp intellectual knife. That knife is so sharp and so swift that sometimes it’s hard to even see it moving.

When one describes a part of the world of which one is conscious, one takes that deadly knife and attempts to name the parts which make up a whole. This and that. Here and there. Black and white. Now and then. Slicing the universe into bits. And the bits eventually end up being very small. They run all the way down to the essence of our being.

Sometimes this is done consciously. For example, I can take a look at my desk: it consists of the top surface on which everything readily needed rests, a few shelves, a cupboard and three drawers. This is a perfectly fine description for me, as a user of the desk.

However, were I to ask a carpenter to build a copy of the same desk, I imagine he would perceive it a little differently. Most of the desk is made of wood, that’s no problem, but there are also drawer slides and hinges which need to be ordered from a metalworker. The handles for the cupboard and the drawers are identical and made of plastic, plus there are bits in the slides which are also plastic, they need to be sourced from somewhere else as well.

And then I can ask my wife what she thinks the desk looks like, and she might tell me that it’s brown - the colour matches the bookshelves, - quite large, sturdy and that it fits the rest of my office well.  

Seems like the desk can be named and organised quite differently depending on who looks at it. It can be sliced up in a number of ways, and it can be put together with other things, too, like the shelves and the office. What is obvious, though, is that this process happens all the time. Every nanosecond in someone’s mind somewhere, the knife cuts something. Slicing and assuming that everyone else’s knife slices the same way is asking for trouble.

# Deep cuts

There’s no particular reason to believe that the knife ever stops working. The ancients believed that it stopped at the atomic level. The [name](https://en.wiktionary.org/wiki/%E1%BC%84%CF%84%CE%BF%CE%BC%CE%BF%CF%82#Ancient_Greek) Democritus gave to the fundamental particle of the universe means “indivisible,” or, more literally, “uncuttable.” We might have entertained the thought of atom’s immunity from the knife until the 1900s, but, with the discovery of the subatomic particles, the analytic knife proved to be sharp enough to cut even through the uncuttable.

The cuts run deep, to the very foundations of reality. But there is also the inverse of the knife, when things are put together in order to form larger structures. The way everyone understands the world is a network of cuts and seams. Cuts start at the top: I see a desk, then cut it up into the drawers, planks, screws, splinters, all the way down into grains of sand smaller than the smallest subdivisions of quanta, clouds of tiny dust. Seams start at the bottom: quarks, protons, atoms, molecules, cells, all the way to The One, a monistic perception of reality. Somewhere, sometimes, the two meet. The precise way this structure works is different for everyone. This is fundamental to my worldview.

We can move up and down that tree of abstractions. Can we move sideways? What if we applied the knife to the nature of analysis and synthesis? There are, after all, certain groupings of cuts and seams which seem to be more evident than others, more easily discovered. In my mind, that kind of grouping is called an *abstraction*.

# Abstract thinking

I think of abstractions in terms of packing. Out there is a big world, and here I am, with my small head. I need to meaningfully pack the big world into my small head, so I cut it down and stich it up into a form that fits. An abstraction is just that: a way to fit information about the larger world into one’s mind by means of organising principles in which the specks of tiny dust of reality interact with each other.

Abstractions are plentiful and ubiquitous to every creature. They start at the most fundamental, pre-intellectual level of everyone’s and everything’s interaction with reality. The way sense organs transform information about photons hitting the retina or particles hitting the skin is possibly the one which is most understandably low-level, that goes up and up all the way to completely immaterial ideas like mathematics and theology.

However, every abstraction (except [one](https://en.wikipedia.org/wiki/Logos_(Christianity))) is imperfect, because every abstraction is limited by our experience as creatures in the world. Only divine knowledge of the precise state of the world can produce an abstraction which precisely explains everything that goes on in it. However, that knowledge is not available to us, since we as humans experience the world through our own abstractions. Nor would it be available to any [system or simulation](https://en.wikipedia.org/wiki/Laplace%27s_demon) existing in the material universe — it can only be available to God who is above and beyond it.

As such we can only evaluate abstractions based on how well they correspond to reality and their interaction with other abstractions. Typically, these days, this is done by means of the scientific method: we take a higher-level rational abstraction and see if it matches lower-level empirical evidence. Understood like that, science is basically a process of looking for imperfect abstractions that let us understand the world better and make predictable judgments about the future.

# Truth and usefulness

This is why I have a hard time accepting basically any scientific theory as “true,” because in my framework there are basically two ways the word can be understood.

It can either be applied inside of an abstraction to judge whether a certain idea abides by the constraints and principles of the abstraction itself. For example, we can say that the statement “one is more than two” is true within the realm of mathematics, because the definition of “two” is that it’s one more than “one”. Within the abstraction of Newtonian dynamics we can also truthfully claim that velocity is distance divided by speed. Most people would also agree that the sentence “the Sun rises in the east” is true.

However, these statements become more difficult once we leave their respective abstractions. While conceptually one might be more than two, in the kitchen, one clove of elephant garlic is definitely more than two cloves of softneck garlic. The way one operates in the kitchen is completely different than one does mathematics. The statement is no longer “true” on its own, it becomes meaningless. Like a lemon tree planted in the Arctic, it has nothing to support it and dies. Once you add the theory of relativity, the formula for velocity in Newtonian dynamics no longer works for cases close to the speed of light. The idea of “sunrise” isn’t all that useful in astrophysics.

Hence, the second way the idea of truth is applied is as a blanket judgement of an entire abstraction and how well it corresponds to reality. If the abstraction can be used to predictably achieve desired outcomes often enough that it passes a certain [arbitrary threshold](https://en.wikipedia.org/wiki/P-value), it is judged as true.

However, from the confusion of the two types of truth arise most errors in philosophy. That’s why in my view it’s better to evaluate the correspondence of abstraction to reality in terms of usefulness. An abstraction is more useful than another if it leads to more predictable outcomes in a given situation. A tomato might biologically be a fruit, but saying to a chef that “well, tomato *actually* is a fruit!” should be met with a polite, yet stern, request to leave the kitchen.

# Programming as philosophy

I did not choose the word *abstraction* without a reason. In programming we often work with abstractions, and in that discipline the word is mostly understood as a logical generalization of common functionality. We create abstract classes and abstract things out all the time.

But once you look at the world through the lens of cuts and seams and how they group together, it becomes a useful and eye-opening tool to map the world to code. It’s not an easy thing, though.

Since everyone sees the world through different abstractions, it requires a great deal of understanding to accurately grasp how the users and the designers expect the software to be used. This ability to put oneself in the head of another and try to understand how his abstractions might map to his view of the world I call *intellectual empathy*.

In the course of the work of a programmer it is not only required to empathise with the designer, but, more crucially, with the users. This can sometimes lead to conflicts where certain individual users might have diverging ideas of how a functionality should work. It is on us, as software craftsmen, to reconcile those conflicts and to potentially introduce solutions which might lead to the users to reevaluate their abstractions.

There is also, of course, the matter of which abstraction we choose to map reality into — a sort of third order structure of abstractions (which themselves are a structure of analytic cuts) which we call a *paradigm*. In philosophy, analogously, we could call it a *school* or perhaps an *ideology*. It’s possible to work from the very fundamentals of programming and begin at the level of machine code, but even for that we added the abstraction of hexadecimal representation of bits. Up a few levels and we get to choosing a high-level language, with objects and classes, or maybe functions and monads, following one of the well-established paradigms.

When we make abstractions by the cuts of the analytic knife, there is a certain quality to them. That quality is impossible to perceive, it’s impossible to even talk about, but it’s undoubtedly there. That quality is what is most commonly understood as *elegance*. An abstraction is elegant if it maps well to other abstractions, is easily understood and can be easily extended or reused. For example, our grasp of the requirements of a particular software project can be said to be elegant if it neatly and without much explaining maps onto code and then to working software. Conversely, it is inelegant if we need to do many transformations and mappings to bring it to the line of thinking that everyone involved — users, designers, programmers — can understand.

You can’t really talk about elegance of abstractions in a way which produces anything objectively useful because it is so general. I suppose the closest anyone’s ever come to it were the authors and practicioners of [DDD](https://en.wikipedia.org/wiki/Domain-driven_design), which emphasises making the code reflect the business domain as much as possible, but even that fails to capture the question of elegance in its entirety.

All of this working with abstractions is of course something that’s been done for thousands of years by philosophers. They sliced up the real world with the analytic knife and piled up abstractions in order to answer the most fundamental questions about existence. In the process, they made our lives easier by coming up with processes that led to discovery and invention. This is precisely what programmers do these days, however instead of waiting years or centuries for the impact of our ideas, we get them in an instant — depending on the speed of the compiler.

This is how programming, Christianity, and philosophy has impacted my way of seeing the world. I know most people don’t think like that, most people don’t even need to consider their own epistemology and what they think is true. A large part of what we think is true in the modern world, especially nowadays that the influence of Catholicism on our thinking is lessened, doesn’t really follow from anywhere. Like cut flowers, it has lost connection with its roots and under closer scrutiny is found wanting. It’s sometimes valuable to stop and think why the roses don’t smell like they used to.


How I See The World


Towards the end of the last post about lenses I mentioned that “lenses form a monoid under composition.” I realise in hindsight that that sentence is pretty vague for a tutorial post, however the concept of a monoid is very useful. It’s good to be able to spot them in the wild, because, much like isomorphisms, they give an intuition for what can be done with a construct that has certain properties.

First of all, what is important to understand is that monoid isn’t a type or a function but an algebraic structure. An algebraic structure in the context of programming is a construct that has three things: a type, a set of operations on that type, and a set of rules that the former two must abide by. This is a pretty general definition, and it isn’t immediately obvious what would be the use of knowing about that in everyday work. However, there are a few well-defined structures for which if we can prove that a type satisfies them, we can get something from them for free, which trains the programmer’s intuition for spotting solutions to more general problems.

In order for a type to be a monoid, there needs to be an *internal binary operation* on that type that’s *associative*, and that the type includes an *identity element*.

An “internal binary operation” is a function that takes two elements of a type (hence *binary*) and returns an element of the same type (hence *internal*). In the [previous post](https://www.intercaetera.com/posts/lenses) we implemented a function `composeTwo` that took two lenses and returned a new lens that was a composition of the two. A simpler example is the addition of integers. In the expression `1 + 2`, `+` is the binary operation taking the two arguments `1` and `2` which are elements of the set of integers. That expression evaluates to `3` which is also an integer.

From primary school arithmetic we know that one of the properties of addition is associativity, which means that no matter how we group the operations, the results will be the same. Both `(1 + 2) + 3` and `1 + (2 + 3)` evaluate to the same number. 

The final element to our definition of a monoid is the inclusion of an identity element. “Identity” in this case simply means “neutral.” Much like the identity function does nothing, the identity element makes the binary operation do nothing when it is given as one of the arguments. In the case of addition of integers, that neutral element is of course `0`.

When we have a type T that implements an associative binary operation Op, we can say that “T forms a monoid under Op.” Integers form a monoid under addition and multiplication, functions form a monoid under composition, and so on.

# An aside about reducers

The most useful conceptual advantage we gain from using and understanding monoids is that we can think about monoidal data structures in a way that’s not much different than arithmetic. The operator for concatenating strings is `+` and in many languages the operator for concatenating lists is `++`, immediately evoking the idea of adding things. Modelling our domain objects as monoids allows us to think about them in a similar way.

However, the biggest practical gain from working with monoids is that they are reducible.

There is (or was a while back) a controversy about the use of `Array.prototype.reduce` which supposedly makes code unreadable and difficult to grasp. There even are [ESLint plugins](https://github.com/sindresorhus/eslint-plugin-unicorn/blob/main/docs/rules/no-array-reduce.md) forbidding the use of the method. However, banning it altogether in my opinion is throwing the baby out with the bathwater.

Recall that the `.reduce` array method takes two arguments: a reducer in the form of `(accumulator, currentValue) => newAccumulator` and an initial value which gets substituted for the accumulator on the first run of the reducer. There are, as far as I can tell, two valid ways one can define a reducer, and they have got to do with types of the arguments and the return value.

The first way is a reducer with the signature of `(T, U) => T`. Here, the type of the accumulator is different than the type of the array on which it operates. Most of the time, this is because the reducer actually does more than one thing: it performs data conversion alongside reducing the array. Whereas this might be sometimes considered more performant, it is unlikely to be faster than a for-loop if performance is a concern, and it is definitely not going to be more readable than a combination of `.map` and some kind of join, where the two concerns are separated.

The second way is if the reducer is reducing the same type of value, i.e. its type signature is `(T, T) => T`. Here, the accumulator and every value of the array have the arbitrary type `T`. This is actually the definition of an internal binary operation, the same which we need for a monoid. What’s more, the initial accumulator more often than not will be the identity element of the same monoid.

Furthermore, if we are dealing with a particularly large collection of data with a monoidal type that needs reducing, thanks to the associativity of the binary operation the reduction doesn’t need to be sequential. We can split the computation across multiple cores or even machines and we are guaranteed to have the same result as if we did that computation in a single thread as long as we can then put it together in the right order.

# Lenses as monoids

In the post about lenses we didn’t prove that there exists an identity lens that we can compose. However, we can very easily construct such a lens:

```javascript
const identity = {
	view: a => a,
	set: (s, a) => a,
}
```

This lens isn’t very useful on its own. We can compose it with another lens and we will get back a lens that does the same thing:

```javascript
const addressId = composeTwo(address, identity)
const idAddress = composeTwo(identity, address)
// addressId, idAddress and address are the same
```

Now, in the previous post we implemented the generalised `compose` function like this:

```javascript
const compose = (...lenses) => lenses.reduce(composeTwo)
```

This isn’t quite right, because should we run `compose()` without providing any lenses to compose, we will get a runtime error. Instead, we would expect to get the identity lens back. To properly ensure that our implementation of lenses satisfies the properties of a monoid, we should implement compose like this:

```javascript
const compose = (...lenses) => lenses.reduce(composeTwo, identity)
```

It should at this point be evident why monoids are quite useful. Instead of thinking about ways of arbitrarily composing many lenses, we only needed to consider how to compose two and find the monoidal properties. Having found them, it was very simple to generalise the composition of two lenses to the composition of arbitrarily many.

# Appendix

<c.TableContainer my={4}>
<c.Table variant="simple" size="sm">
<c.TableCaption>A few examples of monoids</c.TableCaption>
<c.Thead>
<c.Tr>
<c.Th>Type</c.Th><c.Th>Binary operation</c.Th><c.Th>Identity element</c.Th>
</c.Tr>
</c.Thead>
<c.Tbody>
<c.Tr><c.Td>Number</c.Td><c.Td>`+`</c.Td><c.Td>`0`</c.Td></c.Tr>
<c.Tr><c.Td>Number</c.Td><c.Td>`*`</c.Td><c.Td>`1`</c.Td></c.Tr>
<c.Tr><c.Td>Number</c.Td><c.Td>`Math.max`</c.Td><c.Td>`-Infinity`</c.Td></c.Tr>
<c.Tr><c.Td>Number</c.Td><c.Td>`Math.min`</c.Td><c.Td>`Infinity`</c.Td></c.Tr>
<c.Tr><c.Td>Boolean</c.Td><c.Td>`&&`</c.Td><c.Td>`true`</c.Td></c.Tr>
<c.Tr><c.Td>Boolean</c.Td><c.Td>`||`</c.Td><c.Td>`false`</c.Td></c.Tr>
<c.Tr><c.Td>String</c.Td><c.Td>`String.prototype.concat`</c.Td><c.Td>`''` (empty string)</c.Td></c.Tr>
<c.Tr><c.Td>Array</c.Td><c.Td>`Array.prototype.concat`</c.Td><c.Td>`[]`</c.Td></c.Tr>
<c.Tr><c.Td>Function</c.Td><c.Td>`(f, g) => x => g(f(x))` (function composition)</c.Td><c.Td>`x => x` (identity function)</c.Td></c.Tr>
</c.Tbody>
</c.Table>
</c.TableContainer>



Monoids in Practice

Last time we talked about isomorphisms and I mentioned at the end of the [post](/posts/isomorphism-in-practice) that there is a kind of “weaker” isomorphism that lets us update immutable nested objects via a pair of functions — one that retrieves a part, and one that updates a part in an existing object.

This kind of structure turns out to have a name — lens — and there is actually a lot more to it than meets the eye. It’s a part of a bigger family of concepts called optics, which provide ways to access and manipulate parts of different kinds of modular data. They originate in [Haskell](https://hackage.haskell.org/package/lens), however they’ve been making their way into other languages as well.

Lenses are definitely the most common and useful type of optic especially in JS, where updating immutable data is verbose and not particularly clean. There have been attempts to make it less so, via libraries like Immutable or Immer, however lenses are something that is much easier to explain, there is a lot less magic involved and you can actually write your own lens implementation is just a few lines of code.

# Product types

Briefly, a lens is a composable getter and setter for product types. Let’s work backwards through this definition. A product (or intersection) type is a data type that combines multiple types into one. For example, a tuple of `[2, 'two']` is a product type combining a number and a string. The most common product type in JS is an object, and it will be the focus of the rest of this article.

Consider the following object:

```javascript
const user = {
	name: 'John Doe',
	age: 29,
	address: {
		street: 'New Street',
		city: 'Birmingham',
	},
}
```

`user` is a value of a product type of a string, a number, and another object which itself is a product type of two strings. We typically ignore the key types since the object type itself is isomorphic to a tuple containing those values, so ultimately the keys don’t really matter.

To access the value of the city key isn’t difficult:

```javascript
const userCity = user.address.city // == 'Birmingham'
```

The only issue that could potentially arise from this method of accessing properties is that the `.` operator can throw an error if the value on the left of it is not an object. This has been a serious concern for a long time in JS that required meticulous null-checking, until we got the “[wtf operator](https://youtu.be/R2idkNdKqpQ)” in `?.`.

Updating the user’s city in an immutable way — that is, returning a new object with the field updated — is a lot more difficult. We can’t just assign a new value to the `user.address.city` since that would mutate the object. Instead we have to resort to spreading the remaining values on every intermediate level, which is not only error-prone and verbose, but also very tightly couples the logic of retrieving nested fields with the data itself.

```javascript
const userInLondon = { 
	...user,
	address: {
		...user.address,
		city: 'London',
	},
}
```

# Getters and setters

Getters and setters are pairs of functions that retrieve a value and update it. By convention, they are called `view` and `set`. Alternatively, you might find it helpful to think in terms of “unwrapping” and “wrapping” values. (Viewing is like “unwrapping” a smaller value from a larger context, setting is like “wrapping” a smaller value into a larger context.)

`view` is a function that takes a value of a product type and returns the focused value. A `view` function for the `name` field of our user (or indeed any product type containing a value under that key) would look like:

```javascript
const view = user => user.name
```

`set` is a function that takes a whole value, a new focused value, and returns a new whole value. Again, for the `name` field it would be:

```javascript
const set = (user, newName) => ({ ...user, name: newName })
```

Now, this pair of functions is only good for the `name` field. It would make sense to create a factory which would let us use them for any field.

```javascript
const createLens = field => ({
	view: whole => whole[field],
	set: (whole, part) => ({ ...whole, [field]: part }),
})
```

Now that we have packaged a lens into an object with its two functions, we can make utility functions that do more with the lens. We can create “standalone” `view` and `set` functions that take a lens and apply its functions. We’ll also create a function that applies a given function to the focused value. Conventionally this kind of function is called `over`.

```javascript
const view = (lens, whole) => lens.view(whole)
const set = (lens, whole, part) => lens.set(whole, part)
const over = (lens, whole, fn) => set(lens, whole, fn(view(lens, whole)))

const upcase = str => str.toUpperCase()
over(createLens('name'), user, upcase) // == { name: "JOHN DOE", ... }
```

# Composition

Since a lens is actually just a pair of functions, it turns out that we can compose them as well. This is what makes lenses so neat and powerful. To view the `address.city` field:

```javascript
const address = createLens('address')
const city = createLens('city')

view(city, view(address, user)) // == 'Birmingham'
```

And likewise to set it:

```javascript
set(address, user, set(city, view(address, user), 'London')) 
// { address: { city: 'London', ... }, ... }
```

This isn’t much less verbose than the previous example with object spreading, however we can generalise it into a utility function. It looks pretty ugly, but thankfully we only need to write it once.

```javascript
const composeTwo = (outer, inner) => ({
	view: whole => view(inner, view(outer, whole)),
	set: (whole, part) => set(outer, whole, set(inner, view(outer, whole), part)),
})
```

Lenses form a monoid under composition, so now that we have a way to compose two of them, we have a way to compose arbitrarily many:

```javascript
const compose = (...lenses) => lenses.reduce(composeTwo)
```

And so now:

```javascript
const addressCity = compose(createLens('address'), createLens('city'))
view(addressCity, user) // == 'Birmingham'
set(addressCity, user, 'London') // { address: { city: 'London', ... }, ... }
```

# Beyond objects

It’s worth noting that the `createLens` factory that we wrote up earlier is only good for objects and their keys (hence you will most often find it actually called [`lensProp`](https://ramdajs.com/docs/#lensProp)). We can create lenses for other product types. For instance, let’s create a lens that returns the first element of an array. We will assume that the element always exists, though in a real application it would be best to ensure that by some other means.

```javascript
const first = {
	view: ([f]) => f,
	set: ([_, ...rest], f) => ([f, ...rest])
}

view(first, [1, 2, 3]) // == 1
```

Since `first` is a lens like any other, we can compose it with other lenses.

```javascript
const user = {
	name: 'John Doe',
	age: 29,
	address: [
		{ street: 'New Street', city: 'Birmingham' },
		{ street: 'Abbey Road', city: 'London' },
	]
}

const addressFirstCity = compose(address, first, city)
view(addressFirstCity, user) // == 'Birmingham'
```

Before wrapping up, a curveball. Let’s take a look at a less useful but nonetheless interesting application of lenses. We can think of integers as a product type of a sign and a natural number. And if it’s a product type, we can try to write a lens for it.

```javascript
const sign = {
	view: n => n >= 0
	set: (n, sign) => sign ? Math.abs(n) : -Math.abs(n)
}

view(sign, 1) // == true
view(sign, -3) // == false
set(sign, 3, true) // == 3
set(sign, -5, true) // == 5
set(sign, 4, false) // == -4
```

# Beyond lenses

Lenses are just one of the many different kinds of [optics](https://mpickering.github.io/papers/profunctor-options.pdf), that is, methods allowing for modular data access. Other types of optics include prisms (which are analogous to lenses, but for sum or union types rather than product types) or traversals (which allow multiple foci). There are multiple methods of expressing optics and there are many libraries in various languages implementing them.

For me, optics are among the most rewarding tools in functional programming. They solve a pervasive problem of manipulating values inside data structures in an immutable way and they do so without boilerplate. There is a [certain beauty](/posts/romantic-programming) to them that I appreciate and they manage to be very useful to boot.


Lenses for Immutable Data

It seems cliché in these times to point out that the spirit of Christmas is gone somewhere. Yet it is tremendously difficult to point out where it’s gone, why it’s gone, and perhaps most importantly, what it was. It’s just fashionable to say that it’s gone, and leave it at that. 

Some say that it was replaced by the spirit of Christmas shopping, the omnipresent commercialisation of the atmosphere with Coca-Cola Santa Clauses, cheap polyester red hats, and even cheaper plastic decorations that go up after Halloween and disappear on the evening of the twenty-fifth. It’s even more fashionable, especially among the Puritan-descended liberals who say that it’s good that it’s gone, that it is not inclusive enough, that there are many other winter holidays that people celebrate (they don’t), that it’s backwards and medieval. Others still focus on the nostalgia, stuck in the “good old days,” turning Christmas into another All Souls Day, remembering relatives who passed away and reminisce about how the olden days used to be better, that the carols used to be nicer, the Christmas tree greener, the gifts brought more happiness. 

Some friends of mine say that Christmas is much nicer when there are children around. That children make them care about the festivities more, that because of the kids they put in more effort. When there aren’t children around, they don’t really want to bother with dressing up the tree, packing gifts, cooking dinner. Just open up a bottle of some nicer wine, order sushi, watch Netflix. Or just hop on a plane and go on holiday to somewhere where it’s a bit warmer, to get away from the insufferable extended family.

I don’t know about any of it, really.

Christmas was just *okay* when I was an atheist. An occasion to get together with the family. A nice dinner together, in an era where everyone is already so busy that there is no opportunity to eat together. For the rest of the year everyone would just heat up leftovers and consume them in a rush in front of the television or the computer screen. It was nice to sing Christmas pop songs, to open up presents, to look at the pretty tree.

But when you look at it through the lens of the faith, all of these things are just the shiny silver wrapping of the real gift inside. What the true joy of our existence is is far removed from the post-human and post-God polyester Santa hat. Yes, it’s nice to sing *Silent Night* in a dozen different languages, to eat dinner together, to open up presents, but that’s just the circumstance, the wrapping. The gift is not the shiny wrapping, the sense of our being is beyond the tree, the dinner, the presents, the ribbons and the cheap plastic stuff. Yet, the first to complain of the commercialised atmosphere of Christmas are rarely the first to mention the birthday boy.

Christianity needs Christ to exist, but the Christ doesn’t need Christianity for the fullness of his glory. That’s why Christmas is a celebration of the Child, the Nativity, the Life. A particular Child, Nativity and Life. And that’s why it needs to move beyond the wrapping, every year, because every year we all seem to collectively forget it.

We celebrate life, life that triumphs over death. There is, indeed, often a moment of nostalgia caused by the missing people at the Christmas dinner table, but there is also joy at the ones that are there, and weren’t the previous year. And there is hope. But the hope is not for the return of the “better days” that have come and gone, but for the new day that is to come, tomorrow, next year, and in the next world.

The old are consumed by nostalgia, the young are consumed by bitterness. When they try to celebrate, it’s a marathon of gift wrapping air, just a day off to eat pizza and ice-cream looking at a screen under a blanket, or a two-month-late ritual of seeking closeness to the deceased. None of the three has anything in particular to do with Christianity.

But as everyone who glimpsed the nature of the solemnity of the nativity of the Lord, we are above all of this. We walk straight up among those crawling on their knees. We have to, there’s no other way, once one has the understanding of what is going on. Yes, we will spare a prayer for the dead. Yes, we will glance with aversion towards that one particular relative, chastising ourselves to remember that love is overcoming the inimity.

What makes us walk straight up is that we are all the Church. We received the grace of faith, by no merit of our own. It’s not a matter of our birth, or our status, or our nationality, or our race. We are above all of it because we know that the 25th of December is the celebration of life. The birth of the Christ. [The day the Word was made flesh and made his dwelling among us](https://www.youtube.com/watch?v=xCidGQmPXSU). The rising sun.

For unto us a Child is born, unto us a Son is given; and the government will be upon His shoulder. And His name will be called Wonderful, Counselor, Mighty God, Everlasting Father, Prince of Peace.

And when we weep and pray on Christmas Day, we weep and pray for those who did not attain this grace. For those who sit in the night, playing with a piece of wrapping paper in their fingers.


Inter
Caetera

Recent posts

InterCaetera

Recent posts

Inter
Caetera