Lisp is for Stupid People

[yes, the title is clickbait.]

I’ve been programming in Lisp for many years. It has a reputation as language only suitable to forbiddingly smart people (and indeed, most Lisp programmers I know are MIT-trained or the equivalent). I never quite understood that though. In fact, I realized recently that the reason I like Lisp, why I am always drawn back to it despite its general lack of commercial marketability, is not because I am so smart, but because I’m so stupid.

Or, more precisely, it is because Lisp is a better tool for overcoming my own mental limitations. It’s not that I am particularly stupid – my limitations are largely shared by everybody else. My attention is limited, my processing capacity is limited, my short-term memory capacity is limited, simply by virtue being a human being.

Programming is thought to require being able to hold complicated structures in the head. Here’s a cartoon illustration, which is pretty accurate as far as it goes, and here’s some actual interesting research on programmer’s mental functions. It may be that the fabled 10x or 100x programmers are just a little bit better at dealing with complexity than normal. I’m pretty good at it, but not superhuman, especially now that I’m getting alarmingly old.

The alternative to requiring programmers to be amazing jugglers of objects and acrobats of attention is powerful abstraction and good design. Abstraction is the basic way in which programmers encapsulate a bit of complexity in a single object or function call. All programming languages let you do this but some make it easier and/or offer more ways to do it. Good design means organizing a system around a few fundamental principles so that things make sense and navigating through the code doesn’t require a lot of effort.

These qualities are linked. Clean design means choosing abstractions so that they work together in powerful ways, and better abstraction tools make it easier to do that. It is certainly possible to do good software design in a less-powerful language. Some of the most impressive pieces of software design I’ve seen recently has been the series of visualization libraries coming out of Jeff Heer’s group, including prefuse (in Java) and the newer d3.js (in Javascript). The designers of these libraries have carefully chosen their abstractions so they fit together in powerful ways.

But, I maintain, it is a lot easier to do this in a language that is designed for it, and Lisp is that language. In Lisp, macros and other features make it trivially easy to hide all the details away in suitable abstractions, with the result that the meat of the program can be compact, so that the programmer can focus on it. In Java, by contrast, the important part of a program generally tends to be hidden away amidst boring boilerplate code that is necessary to please the Java compiler but not germane to the problem at hand (this article refers to the novel software metric “beef-to-bun ratio”, which is low in Java but apparently improving).

Thus Lisp has always seemed to me a much better tool than any other for augmenting my own limited brain functions. I don’t know why the rest of the world, presumably equally suffering from the same limitations, doesn’t see it that way.