Bill Clementson's Blog

Common Lisp is the Borg of programming languages

Friday, April 2, 2004

There is a thread on c.l.l. that discusses Paul Graham's Arc project (a new dialect of Lisp). Will Hartung provides an excellent explanation as to why many Common Lisp programmers are not that interested in Arc (clarification: many are interested in Arc as a way of gaining "mind share" for Lisp but not many see it as an alternative that they would choose in preference to CL) and why most of the interest in Arc comes from outside the CL camp (Note: the highlights are mine):

"You have two camps, those in the Common Lisp camp, and those outside of it.

You can be inspired by Common Lisp, based on Common Lisp, taking ideas from Common Lisp, etc, but you won't be Common Lisp when you're done.

The reason is that if your final result used Common Lisp as a core, then you're still Common Lisp.

Kenny's Cells is Common Lisp. Uncommon SQL with its embedded SQL reader macros is Common Lisp. The LOOP Macro is Common Lisp. Uncommon Web, with its limitations and limited CPS macros, is Common Lisp. CLOS is Common Lisp. Garnets KR is Common Lisp.

But, for example, AspectJ, is not Java. Java like, Java inspired, sorta looks like Java, Works with Java, but not Java. They could have done Aspect C++, or AspectPython, or AspectIntercal.

Why the distinction? They had to go outside the domain to implement it. If I throw an AspectJ program at a system that 'knows Java', it will go 'WTF? THIS isn't Java.'

You can not extend the Java language.

The built in Common Lisp compiler compiles all of the previous contstructs. AspectJ needed its own compiler.

It is said that the lathe is the only machine that can actually reproduce itself. That's how Common Lisp is. It can reproduce itself, expand itself, grow itself.

Once you've defined a new Common Lisp construct, the borg that is CL absorbs and consumes it, and makes it one with itself.

You'd like to think that the Scheme's of the world are similar, but, going on the most base RxRS versions, the language itself isn't rich enough to extend itself. A simple example is things like structures/records. Basically in Scheme, they're implemented as either lists or arrays, with a layer of macros on top of it. But if you ask the type of the object, you won't get structure/record, you inevitably get list or array. It's difficult to make the new type opaque to the system.

So, while many packages exist to add structures to Scheme, most implementations pick a representation and build it into the system, into the compiler, which is typically NOT written in Scheme. The point here is while Scheme is a dynamic and extensible language, I don't think that Standard gives enough of a foundation and most implementors must move beyond it.

Something like Arc COULD be written on top of CL. A more succinct system, shorter names, even its own reader and listener. Then, Arc becomes a domain specific extension of CL, like, perhaps, the HTML extensions, but you always have CL if you ever needed it. Run into an brick wall? You can fall down into CL and fix it.

But, Arc doesn't want to be a CL macro, package, and library layer. Best to reinvent the entire wheel.

Lisp has reinvented itself, and been renewed with changes that can only be done by restarting from scratch, and that's fine, all hands on deck, balls out, full steam ahead. But every proposal regarding CL I've seen wants to toss out the baby, bathwater, basin, sponge and soap to get their new idea. They want a sorta kinda maybe thing like a little almost Common Lisp.

'I love Common Lisp, that's why I want to toss half of it out and restart the other half from scratch to I can slowly rebuild it to 75% of what Common Lisp was before I started!'

I'd be more interested in some hacker that wants to implement something like Dylan's sealing into a CLOS-esque system by hacking CLOS code and the CMUCL compiler. Something like this needs compiler support to gain the actual benefits, but that doesn't necessarily mean that everything else has to go with it at the same time. Not that this is a particular pet peeve, but this is one of the things that Dylan was trying to accomplish and felt they needed to redo the entire thing (perhaps they did, I don't really know).

Most of the other CL complaints have to do with the implementations and portable functionalities (sockets, threads) (which single implementation languages don't have), and holes in implementations (like the MOP -- which, to be fair, like sockets, isn't in the Standard). Those can be, and have been, fixed without tossing out CL."

"If you give someone Fortran, he has Fortran. If you give someone Lisp, he has any language he pleases."