Paul Graham is perhaps best known for two things: co-founding Y Combinator, and his tireless advocacy of LISP programming languages. And on Saturday, the legendary investor and essayist released his own LISP dialect, called Bel.
What I've been working on for the last several years: Bel. https://t.co/Tk9KFlw8Gl
— Paul Graham (@paulg) October 12, 2019
Bel is interesting, not least because it highlights the enduring and improbable longevity of one of the earliest high-level programming languages. That’s no small feat, especially given the hype-driven nature of the software development sphere, where front-end JavaScript frameworks emerge and disappear on a near-weekly basis.
That said, before we delve into the technical weeds, it’s probably worth doing a bit of a recap on LISP.
The origins of LISP
The <3 of EU tech
The latest rumblings from the EU tech scene, a story from our wise ol' founder Boris, and some questionable AI art. It's free, every week, in your inbox. Sign up now!
LISP started life in 1958, when mathematician and computer scientist John McCarthy published a paper called “Recursive Functions of Symbolic Expressions and Their Computation by Machine, Part I.” His goal was to create a system of mathematical notation for algorithms, rather than a fleshed-out programming language. History, however, had other ideas. McCarthy’s ideas caught traction, and a few years later, researcher Steve Russell wrote the first LISP interpreter on an IBM 704 computer.
For the next thirty or so years, LISP would be an area of focus for computer scientists. The language fragmented into multiple distinct and interesting dialects which pioneered concepts still used today, like running code through REPL (read, eval, print loop) environments. Much of the early work in AI was also written in LISP.
Beyond the academic sphere, LISP found favor with a vocal niche of developers, most notably Paul Graham and Eric Raymond. Although it lacks the mainstream success of Python and Java, there are those who insist it’s the greatest thing since sliced bread. And LISP’s advocates make a compelling case.
LISP inherently lends itself to the creation of code that’s readable and expressive, as explained by Peter Serbel:
…a Common Lisp program tends to provide a much clearer mapping between your ideas about how the program works and the code you actually write. Your ideas aren’t obscured by boilerplate code and endlessly repeated idioms. This makes your code easier to maintain because you don’t have to wade through reams of code every time you need to make a change. Even systemic changes to a program’s behavior can often be achieved with relatively small changes to the actual code. This also means you’ll develop code more quickly; there’s less code to write, and you don’t waste time thrashing around trying to find a clean way to express yourself within the limitations of the language.
And in the same way that learning Latin makes you better at languages, many argue that learning LISP makes you a better programmer. Here’s what Eric Raymond wrote in his essay titled “How to become a hacker:”
Lisp is worth learning for the profound enlightenment experience you will have when you finally get it; that experience will make you a better programmer for the rest of your days, even if you never actually use Lisp itself a lot.
Meet Bel
So, let’s go back to Bel.
Some readers will already know that Graham already created his own LISP dialect, called Arc. Bel is separate to that.
Perhaps the most intriguing facet of Bel is that its development is intended to mirror that of the original LISP spec as much as possible, even if the language diverts from it in some parts.
Just like LISP started life as a system of notation and later evolved into a fully-fledged programming language, Graham wants to keep Bel in its incubation period for as long as possible. Here’s what he wrote in the guide to the language:
Bel is an attempt to answer the question: what happens if, instead of switching from the formal to the implementation phase as soon as possible, you try to delay that switch for as long as possible? If you keep using the axiomatic approach till you have something close to a complete programming language, what axioms do you need, and what does the resulting language look like?
By doing this, Graham hopes to answer the question: “If computers were as powerful as we wanted, what would languages look like?”
Bel is an interesting experiment, and I’m interested to see where it leads. Although Graham has published a guide to the language, along with some source code, I’d recommend you hold fire before you add it to your LinkedIn profile. “This is not a language you can use to program computers, just as the Lisp in the 1960 paper wasn’t,” Graham wrote.
Bel was so much more work than you'd guess from looking at it. But this seemed a good sign. I can't stand wasting time, and if one can spend a lot of time on a project without feeling one is wasting it, the project should be proportionally promising.
— Paul Graham (@paulg) October 13, 2019
Although he has no plans to write a formal implementation that would allow developers to write Bel programs (at least, not just yet), Graham has no qualms with the community making one.
“If you’d like to try writing an implementation based on Bel, please do. I’ll be one of your first users,” he said.
Get the TNW newsletter
Get the most important tech news in your inbox each week.