// HACKER NEWS — CYBERSECURITY
What makes Lisp difficult to read?
The Lisp family of programming languages is infamous for their parenthesis-heavy syntax. Many people, myself included, find this syntax more difficult to read than the notation of languages like Python, Java or C. The perceived unreadability of Lisp is significant enough that multiple attempts have been made to create new notations to aid Lisp’s adoption. Yet, despite these attempts and Lisp being nearly as old as computing science itself, I have not yet encountered a fully satisfying explanation as to why Lisp is perceived as being less readable.
Lisp developers commonly argue that this is simply an issue of familiarity; Lisp notation is less common than C notation and programmers are therefore less used to reading it. Once you get used to programming in Lisp you don’t even notice the parentheses, allegedly. I believe there is more to it, and that with a deeper investigation we may gain insight into how to design pleasant syntax. In this article I will explain my theory as to why Lisp’s notation – specifically its placement of parentheses – requires more effort to parse, inspired by some observations from cognitive science.
For those who might not be familiar with Lisp’s notation, in a typical Lisp program every statement, expression, and function call is written with the same syntax: (operation arguments...). Compare the definition of a recursive factorial function in Lisp (Scheme) and an equivalent function in JavaScript:
You will notice that the Lisp sample lacks infix notation (n == 1), keywords (else) and different types of delimiters ({}). These differences tend to receive most attention in discussions of readability. While I agree that these notations have some effect on readability I suspect their importance is overstated; beyond familiarity I do not find (- n 1) to be clearly inferior to (n - 1).
The syntactical variance that C-style languages have in these different forms of notations for applications does likely significantly influence readability. I intend to investigate this aspect in a different post. In this post, I will focus primarily on the differences that remain when comparing normal function applications. I.e., why does operation(arguments ...) appear to be more pleasant than (operation arguments...)?
To see why placement of parenthesis matters, we have to consider that human perception does not treat all input equally. To experience this, try to say out loud the display colour of the words below as quickly as possible:
You will find that the second row – where the colour of the text does not match the written colour – is slower to read. This is known as the Stroop effect. Several such effects have been discovered which may hinder or aid visual processing tasks. I like to think of these effects as a kind of hardware acceleration built into our perception machinery.1 As with programming, we should attempt to make the best of the capabilities of our hardware.
For instance, consider the two visualisations of the same dataset below. I have hidden two outliers in the data. One of these visualisations uses a ‘hardware acceleration’ trick to make it easier to find the outliers:
You will no doubt be able to spot the outliers in the second visualisation much quicker than in the first. In fact, for the plain data presentation the search tasks takes about 𝑂(𝑛), whereas the hardware accelerated search miraculously terminates in 𝑂(1). Good designs use this effect to make their interfaces more searchable via e.g. differently shaped icons and highlight colours.
I have chosen the Stroop and pop-out effect to illustrate human hardware acceleration since these effects are pronounced and easy to reproduce. Unfortunately, findings from the cognitive sciences are not all as apparent or well-defined. Application of such effects require a degree of creativity and subjectivity. It is therefore not my intention to suggest that readability is entirely objectively explained by the to be discussed cognitive effects.2 Rat