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.


The Spirit of Christmas


Many who begin their journey with functional programming think that simply applying the principles of pure functions and immutability of data yields benefits to code clarity. While this is undoubtedly true, and these properties are indeed requisite for functional programming techniques to work, they are not in themselves the goal.

There are many lessons in purely functional languages that can be applied in the day-to-day of working with, for example, JS. Most programmers now use `const` exclusively to declare their variables. And while purity of functions is still rarely seen on a large scale, we understand the benefits that it brings, such as predictability, ease of testing and so on. But having immutable data structures and working with pure functions at least in a part of our application allows us to leverage the patterns found in category theory and applied in functional programming that make our code much easier to reason about and work with.

There are many such patterns. Algebraic structures like functors and monads are the first that come to mind. When working with deeply nested data, lenses are likewise very useful. But there is a property underlying all these concepts that is worth noticing and utilising more, and that property is isomorphism.

# Definitions and examples

The formal definition of isomorphism is that two objects are isomorphic if there are functions between them that if composed result in identity. In other words, an object of a type can be transformed into an object of another type and back without losing or gaining any new data.

In JS for example, an array `['a', 'b', 'c']` is isomorphic to a string `'abc'` because one can be transformed into another. One can use the `.split('')` method on the string to transform it into the array, or the `.join('')` method on the array to transform it into the string. They can also be combined into `.split('').join('')` to get back around to what we started with and prove the isomorphic property. 

In more functional languages, such as Haskell, these transformations are [referentially transparent](https://en.wikipedia.org/wiki/Referential_transparency) and so there isn’t any performance cost in moving between them. In JS this isn’t as simple since the different types have different methods, however the performance overhead in transforming one into another is negligible unless both instances are particularly large.

The example of transforming a string into an array of characters is trivial and perhaps not very practical, but there are isomorphisms which are more widely used.

The focus of the array in JS is iteration — it’s an ordered collection of objects and the way one mostly uses it is to `.map` over it or `.find` something in it, `.filter` it or even `.reduce` it to a single value. On the other hand, the point of a JS object is random access: the Object prototype does not implement a `.map` method even though it would be sometimes useful. So is it not possible then to iterate over a JS object?

Most will quickly discover that there is a method `Object.entries` that converts the object into an array of key-value pairs (which are in themselves arrays) that of course allows the use of all the methods needed: map, find, filter and reduce. The array can then be converted back using `Object.fromEntries`. So objects are isomorphic to arrays of pairs, but there are situations where we might want to use one over the other.

Interestingly this is a first-class concept in Elixir, where we have maps — equivalent to JS objects — and keyword lists, which are lists of pairs, where the first of the pair is an atom key and the second some kind of value. Keyword lists are widely used to pass options to functions. This actually led to many new to Elixir asking why even have both. Elixir uses the [recursive definition of a list](https://en.wikipedia.org/wiki/Recursive_data_type#Example) (as opposed to JS where an array is simply a special kind of object), so the “iterative” nature of lists comes into play much more, since inexpensive random access is out of the question. Conversely, though, Elixir also implements the `Enum` module for maps out of the box so rarely is it necessary to convert them to keyword lists or vice versa.

# Usage

Perhaps the most famous mathematical example of applying isomorphism is the underlying principle of analytical geometry which states that points on an infinite, two-dimensional plane with an origin point can be mapped to pairs of real numbers that denote distance from that origin point and back. This was discovered by Descartes in the 17th century and we now know it under the name of “Cartesian coordinates.” It was a revolutionary discovery because by using it systematically it allowed one to translate relatively complicated problems in geometry, involving lines, circles and parabolas, into simpler problems in algebra involving equations of points of coordinates.

This is also possible in programming. If one faces a problem involving a complicated data structure or an unwieldy record, as long as we can find a way to translate it to a simpler form and back, we might be able to find a more elegant and simple solution.

The lofty ideals of consistently pure functions in software are unfortunately hard to attain in every-day, fast-paced agile development. There are deadlines, there are people inexperienced with functional programming, there are external requirements, services and libraries to integrate with. Perhaps the world would be a better place if every application were written in Haskell, but it isn’t, so we have to make do with what we got. This often means relegating the pure functional code to the business domain, where it may make the core of what we build and is then forced to interface with other impure code elsewhere. While the property of isomorphism is not going to make this any less or any more possible, it might make it a little prettier.

Let’s consider a module in an employee schedule application in JS. We have employees, each of whom has a schedule, and the schedules have events that happen during the employee’s shift. For the sake of example and simplicity, we can say that an event record looks like this. It had been implemented years before we had joined the project and in that time nobody had considered the key names are too long, so it is practically impossible to change them. 

```javascript
const event = {
	eventTitle: 'Lunch with Bob'
	startTimeMinutes: 270,
	endTimeMinutes: 330,
}
```

Let’s say that our task is to write a function which detects collisions between two events:

```javascript
const event1 = { eventTitle: 'A', startTimeMinutes: 100, endTimeMinutes: 400 }
const event2 = { eventTitle: 'B', startTimeMinutes: 50, endTimeMinutes: 200 }
const event3 = { eventTitle: 'C', startTimeMinutes: 450, endTimeMinutes: 500 }

const detectCollisions = (event1, event2) => true // @TODO: Implement

expect(detectCollisions(event1, event2)).toBe(true)
expect(detectCollisions(event2, event3)).toBe(false)
```

One way to do this might be to simply use the provided data structure *as-is*. This is going to be a problem because the key names are particularly badly chosen — they are unnecessarily verbose. Also, because they are named properties of an object, they aren’t easy to destructure. Perhaps a better way would be to convert them to an isomorphic structure that is easier to work with.

```javascript
const toTriple = ({ eventTitle, startTimeMinutes, endTimeMinutes }) =>
	([eventTitle, startTimeMinutes, endTimeMinutes ])
const fromTriple = ([ eventTitle, startTimeMinutes, endTimeMinutes ]) =>
	({ eventTitle, startTimeMinutes, endTimeMinutes })
```

Now that we have a function that can translate between the event objects and simple array triples, we can write a function which operates on these triples alongside a helper which tells us if a number `x` is between two other numbers `a` and `z`.

```javascript
const isBetween = (a, z) => x => x >= a && x <= z
const check = ([_, ...first], [__, ...second]) =>
  first.some(isBetween(...second)) || second.some(isBetween(...first))
```

Implementing the `detectCollisions` function now is trivial, as it simply needs to translate the event object to a triple and apply the `check` function. In this case we do not even need to translate the triples back since we expect a boolean.

This approach has a few advantages. Firstly, we do not pollute the function implementation with unnecessary detail because destructuring arrays is concise, otherwise we would have to do something like `{ startTimeMinutes: firstStart, endTimeMinutes: firstEnd }` to change the unwieldy key names to something more usable. Secondly, since we do not care about the names of the events in this function, we can omit them by replacing the names with underscores. This also encapsulates the logic much better, since whoever will read the code should understand that now we operate in the bounded context of event durations. Finally, this implementation is quite extensible. We have a framework within which we can add other functions which deal with event durations, should we need to for instance add new events that match durations, or check if events are adjacent to one another.

It is worth noting that while the event-triple transformation implemented here is purely isomorphic, if the event object were bigger, we might change the translation layer to a sort of weaker form where we only extract the fields we want and then put them back together. Perhaps if we were only interested in the event titles we might say:

```javascript
const toTitle = ({ eventTitle }) => eventTitle
const fromTitle = event => eventTitle => ({ ...event, eventTitle })
```

This approach requires us to remember which objects translate to what in both layers. In practice this means that if we operate on an array of events, we have to remember to keep both the event array and title array in the same order. It also removes the possibility of creating new events if we only have the event title, unless we also have “defaults” to assign to missing fields. Nevertheless, this technique is still sometimes useful.

# Vice versa

Finding isomorphisms in the wild is not always easy. However, mastering this technique allows for finding more elegant, readable and concise solutions to everyday problems. It is also a valuable stepping stone into more advanced FP concepts, such as algebraic structures.


Inter
Caetera

Recent posts

InterCaetera

Recent posts

Inter
Caetera