Lisp Reforms

Problem statement

Ladies and gentlemen, let's face it. Lisp is not a popular language:

In fact, these aren't even the two most popular lisps. Do you want to know what the most popular lisps are? You can probably already guess. If you can't guess, you might have to take hold of yourself before learning the truth. This is a "Luke, I am your father!" moment.

Yes. Them.

You know, even Matlab beats Common Lisp and Scheme on Github. Now you might argue that if all of the Common Lisp and Scheme and Emacs Lisp and Clojure users were pooled together into a single lisp puddle, then lisp would actually come at #5 or something, and people would realise how wonderful lisp is.

But you have to consider, perhaps these numbers would actually be a lot higher if lisp just didn't have so much crap associated with it?

Let's be clear what we mean about crap. Crap is anything that keeps your language in 1973. These days we want clean syntax, good libraries, careful testing, community support, speed, lack of surprises, ease of installation. Some of the lisps have some of these things, certainly! But no single lisp, even Clojure, comes anywhere near to having a majority of them.

What we need, ladies and gentlemen, are reforms.

Attacking the problem

Syntax can be fixed. Libraries can be fixed, though it's a big effort. Community will come when you have other things. The biggest problem that any new language faces is performance. You have to make your language performant, otherwise it's not going to be treated seriously at all.

Virtual machines

To be performant, you're probably looking at targeting a VM these days. Unfortunately the leading VMs all have problems. LLVM is very difficult to garbage collect with, let alone anything particularly complex. The JVM comes with the pain of JVM maintenance and an ancient toolchain. Nobody even uses Parrot, except for the Perl6 wizards.

There are alternatives. You could possibly target asm.js. You might even be able to make a fast language in RPython, much like PyPy and Topaz. In a way, ideally you'd have multiple targets, because constraint of your output means a constraint on what users you get.

Go on then, moan about parentheses

Okay, okay, I know. I know. Lisp programmers love parentheses like users of emacs love emacs and users of vi love vi. But seriously, it's not huffmanised, and programmers can tell. The brain is a finely tuned huffmanisation-guff-detector. It knows, you guys.

The obvious way to accommodate lisp programmers and non-lisp programmers alike in a decent modern framework is to make a standard mapping from some language to parens. In other words, to go MoonScript and CoffeeScript on sexprs. It's the only way!

To a great extent, the implementation details don't matter too much as long as it's consistent and nicely huffmanised. It should make lisp look like a modern language. People who have used Haskell should want to use it. People who write NASM should want to use it. Wizards who write in Perl6 should want to use it. You've just got to keep it clean and consistent, free of surprises.

See also