A Linguistic and Artistic Defense of the Beauty of Code

I have met and worked with many poets and wordsmiths over the years, and one of the most common traits I find amongst them is a striking disdain for mathematics. You can hear it in the room, the collective sigh-laugh whenever math is brought up, a mosh of elbows bumping into ribs, saying, “thank god we never have to do that again!” And where this distaste for algebraic math and arithmetic is found, so too is a dislike for coding as well.

I find most of the writers I work with have so much to say about the beauty of language. Their chests puff out, and they enter an almost trance-like state when they read you one of their favorite poems or recite a quote that is so perfect in its diction, syntax, and composition that it feels like magic coming out of your mouth. There is so much romance in language; however, so many of my writing peers seem to believe that this magic falls short at the computer.

I’m not trying to convince anyone to get a PhD in mathematics. The only part of calculus I ever enjoyed was identities that made equations fun little visual puzzles, and though I maintain a decent knowledge of physics, the math involved with the field is anathema to me. However, I believe there to be such a satisfying beauty and poetry to the language of code, and it is my hope that people might be able to think of coding not as some crude, unfathomable technology, but a language made by humans like all others, and just as beautiful.

The particular language I want to analyze is that of R software, a statistical software used for the analysis of large amounts of data. We’ll start by looking at some of the most important structures of the language.

One of the most important parts of coding in the R language is using ‘packages’. Installing a package in R is similar to if you were to download a list of vocabulary words. Now that you’ve downloaded this package of words, you can use them any way you want, but until installation, you can’t. There are hundreds of packages in R, however, one of the most widely-used is called ‘tidyverse’, a set of multiple datasets typically used for instruction or practice with the R software. However, the most interesting part of installing packages is the way the syntax has to work.

In linguistics, a morpheme is the smallest unit of a word that contains meaning. Let’s take the word ‘dog’ for example. ‘Dog’ has 1 morpheme because it cannot be split into any smaller units of meaning. However, ‘dogs’ has 2 morphemes, because you have the morpheme ‘dog’, which states we’re talking about a dog, but you also have the morpheme ‘s’, which conveys the meaning that there are multiple. There are also free and bound morphemes, units of meaning that can exist on their own, and those that can’t, respectively. So ‘dog’ is a free morpheme where ‘s’ is a bound morpheme, because ‘s’ cannot exist and convey meaning on its own—it must be attached to something. So let’s take a look at the syntax of coding and downloading packages in R.

To download a package, one would type: >install.packages(). The ‘()’ is where a coder must type what specific package they want to install. So, for example: >install.packages(tidyverse). Looking at this linguistically, how many morphemes do we assume this to have? 3. ‘Install’ conveys meaning, ‘packages’ tells the software to specifically install something from its cache of packages, and ‘tidyverse’ specifies the exact package. So what are the free and bound morphemes? All of them are bound. None of these morphemes can exist in R on their own; nothing will happen in the software. What’s so fascinating about this is that the entire coding language of R relies on this kind of specification. In effect, the entire language’s valid phrases are made up solely of bound morphemes. 

It may not be readily obvious why something like this would make me believe in the beauty of code. My personal love for languages in general certainly biases me; however, I think it becomes a bit more obvious when we get into visualizations.

Looking at a dataset of people’s ages and credit scores, you can create a density plot to see what the most common ages in the dataset are with a line of code that reads:

>ggplot(BankData, aes(x = ages)) + geom_density(fill = "thistle", alpha = 0.7, col = "black") 

The main part that’s important to focus on in this code is (fill = "thistle" because thistle, in this instance, is not there for any mathematical purposes, but cosmetic ones. When you open the color guide in R, it gives you a list of all the colors that you can use to make a graph. There are 657 of them. There are 100 grays. One for each shade of shadow, or dust, or cloudy day. This may sound inconsequential, but I believe it is a great piece of evidence to the point that coding is not an unartistic thing. People constantly refer to those at the highest echelons of sciences as maestros, playing, dancing with math, code, etc., all descriptors we typically reserve for artists. However, one does not need to be a genius mathematician to engage in the artistry of coding or the sciences. Having the option to make your graphs visually appealing, to make them any one of 100 grays or more colorful, demonstrates the art inherent in coding and the simple act of creation. 

Coding and math in general get a bad rap for being extremely confusing and crude in comparison to the arts and humanities. However, linguistically and visually, coding is a beautiful language in its own right. There is so much poetry to be found in code; words can’t exist without adjunct morphemes, and there are more grays than I have names for to make visualizations. There’s so much beauty to see in the languages humans have created, if we’re only willing to read the code.