
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.


Isomorphism in Practice


An oft-repeated mantra in agile software development is that “done is better than perfect.” Within the business context of software the surface reading of this aphorism is obvious and self-evident, as a feature that done but poorly functioning might still bringing business value, in contrast to a feature that is still in development and not in production. However, while that is its intended meaning, it does not give any useful advice to how development should be approached and as such tends to suggest that it is permissible to write ugly code that works and never learn anything about why it is ugly or how it can be improved.

Indeed I have seen this quote used to justify a lot of irresponsible behaviour when the spirit of it is not properly explained. The properties “done” and “perfect” concern the *object*. Perfection of objects is not possible in any reasonable capacity, and pursuing perfection of any single object is bound to hit diminishing returns at some point and is therefore unproductive.

What does *perfect code* mean? We might say that it first and foremost fulfills the business purpose, it follows the principles of SOLID, it is written clearly — that is, it is easy to intuit it’s purpose by anyone who is reading it in the future, it enables others to build new features on top of it in the future when they are needed, it is well-tested, typed and documented.

There are a lot of properties of *perfect* code and once presented with a piece that seems to fulfill them all, it would not be challenging to find more ways to “improve” it. This fact seems to underline the premise that it is pointless to chase after perfect code because perfection of the object is unattainable. At some point the piece of code we are working on will be good enough, and the increase in quality coming from adding a new unit test or another refactor will be tiny or, possibly, negative. Another layer of abstraction might make the code more elegant or extensible, but it will impact the readability, especially in the case when it might not need any more extension. Similarly, adding more tests makes the code less modifiable as every change in the production code should also require a change in the tests.

An issue with “done is better than perfect” is misunderstanding it as “done is enough.” A *done* piece of code is perhaps just one that fulfills the business purpose. But no piece of code is an island and there will come a time when it needs to change and influence other elements of the system, and as such it is reasonable to expect a certain level of quality from the code that is committed to the repository. So done might be better than perfect, but done well is better than just done.

Additionally, “done is better than perfect” does not excuse from considering how the code could indeed be more perfect, perhaps with the privilege of hindsight obtained after the last commit. It might not be necessary to act on it and add improvements to code that’s “done” to the codebase, but it is always useful to *think* how it *might* be improved. First because there might come a time in the future where it will *have* to be improved and second in order to develop experience that will allow for deducing ways to get it right on the first attempt in the future.

Instead of perfection of the code, one should strive for the mastery as the programmer. One of the hallmarks of such mastery is the intuition for correct solutions before they are even attempted. Knowledge of modelling, abstractions and design patterns is often invaluable here, as sometimes an hour of good design can save a week of coding. On top of that, when developing features or projects with tight deadlines, you will have to make decisions based on incomplete information, decisions that are unlikely to be correct without a certain amount of intuition and experience.

Careful and deliberate consideration of the solutions already developed and eagerness to look for improvements is another proclivity which distinguishes novices from masters. A novice might finish developing a feature, commit it to the repository, consider his work complete and find something else to do. A master understands that most likely some shortcuts were taken in order to deliver the feature on time and documents possible future improvements or directions for developing planned extensions. Aspiring to mastery means looking for this as well, while understanding that those improvements might not be necessary within the current business context.

There is a difference between mastery and seniority, too. Seniority is a much broader concept, referring more to team-building enterprises, where one is responsible for ensuring that the entire team’s skills are utilised as best as possible. In contrast, mastery is a purely individual pursuit that exists only between the programmer and his tools.


Inter
Caetera

Recent posts

InterCaetera

Recent posts

Inter
Caetera