Code as a thing of beauty

Beauty is commonly described as a feature of objects that makes these objects pleasurable to perceive.¹

When we think of code, we tend to think of it for utility rather than beauty. I think we’re wrong in this regard, and beautiful code is possible, and should be sought after. Writing beautiful code is something that we should strive for, not something that should be thought of as a side effect.

Photo by Alan Jones on Unsplash

I recently had the pleasure of taking Cornell’s course CS 3110, a functional programming course.

The little functional programming experience that I had prior to this course had come from tiny projects in Haskell, which, as legend states, you need a Ph.D. to learn. But, I don’t think the main thing I learned from this course was functional programming, it was beautiful programming.

Let’s take a look at two pieces of code — first, in an imperative language, Go:²

nums := []string{2, 4, 6, 8, 10}
sum := 0
for _, v := range nums {
	sum += v
}
fmt.Println(sum)

And now a functional language, OCaml :

let nums = [2; 4; 6; 8; 10];;
List.fold_left ( + ) 0 nums;;

Which code looks cleaner to you? To me, it’s the OCaml. We used a higher order function called Fold to sum the elements of the list. What does this mean? OCaml’s fold functions (often called reduce functions in other languages, such as JavaScript) simply takes a function, an initial value, and a list. It applies the function to the initial value, and the first value in the list. Then it does it again with the result of that function call, and the second value in the list. And again the third.

So you might be thinking, well, OCaml has this fancy function, but Go could have it too right? It’s just not a part of the standard library. We can reimplement this function in Go:

(open in Go Playground)

func foldLeft(op func(int, int) int, init int, lst []int) int {
	acc := init
	for _, v := range lst {
		acc = op(acc, v)
	}
	return acc
}

Now let’s reimplement this in OCaml

let rec fold_left op init = function
	| [] -> init
	| h :: t -> fold_left op (op init h) t

There’s something really nice about the OCaml implementation. Yes, it does allocate more memory³, but it’s a much nicer implementation. Not only does it fit in two lines rather than 3, but it also uses pattern matching, a language feature in OCaml.

Rather than iterating over the list, we recurse through the list, chopping off the head each time. See that h :: t pattern? It determines what the head of the list is (the first item), and assigns it to the variable h, then determines what the tail is (everything but the first item), and assigns it to the variable t. We pronounce this “h cons t.” :: is the “cons” operator. The [] pattern handles the empty list. We call it “nil.”

What’s even cooler about this, and wouldn’t be possible in most non-functional languages, is that lists are not a built-in data type. You might think that surely OCaml must have a built-in alternative to lists, array perhaps? No! The list type is implemented entirely without arrays! It’s pretty cool. We can implement a singly linked list in OCaml in one line:

type list = [] | ( :: ) of 'a * 'a list;;

Explained from left to right

• type list means that we’re defining a new type, and calling it list
• [] means that the value [] can be used for the type. Here [] is just an identifier. It has no special meaning
• | is the “or.” It means that we’re creating a tagged union. List can also have the value ( :: ) of 'a * 'a list, which means that it can have the value called ( :: ) that holds a value of another type ('a), and a list of that type ('a list).

In fact, this is exactly how the standard library implements lists. The code above is identical to how OCaml implements them! Is that not beautiful? We implement lists in OCaml without any other data type.

And as I mention this, I recognize, that a singly linked list isn’t revolutionary or anything. But in what other (imperative) language can you do this in? Certainly not in any imperative language that I know ⁴.

Now, I understand that beautiful code isn’t something that we usually strive for. Software engineers generally primary strive for working code and then easy to maintain code, but I’d like to make the argument that beautiful code helps use hit these points. First, working code. Beautiful code is easy to understand, therefore, it’s generally easy to see how it works, and easy to spot mistakes! Because beautiful code is easy to understand, it is also easy to maintain. It’s all part of the beauty.

Photo by Wolfgang Hasselmann on Unsplash