One Reason I Don't Miss Chicago Too Much

Photo by Dean Armstrong

A few days a year like this would be fine. Good, even. But it goes on for months, it seems.

I think my skin tanned just a little in the 10 minutes it took to walk and get some coffee.

Why Lisp is Different

This a great summary from Rainer Joswig [via The Blog of Lisp]:

Lisp has a specific world view which makes it less compatible with the current outside world.

Let me list a few.

• Lisp usually needs garbage collection. There are almost no standards for garbage collection systems.
• Lisp programs often have a high cons-rate. Thus Lisp usually needs a very efficient garbage collector to be competitive.
• Lisp has the idea of high dynamisn in the runtime. You can redefine a function and user code will immediately use the new one. You can change a class and existing objects will be changed. You can change an object from one class to another. All this induces additional redirections.
• Lisp in its standard data types does not care that much about data layout. This can be inefficient. Various Lisp dialects have special purpose data structures.
• Lisp has typed objects with identity. Objects carry around their types (often using low-level tags). This again makes Lisp objects in their data layout incompatible with most other systems.
• Lisp prefers heap consistency. Usual operations should not corrupt the heap in the presence of dynamic typing. This makes it necessary to check operations before they are applied to objects. Untagged objects are cannot be checked without knowing their types from somewhere else.
• In the presence of large virtual memory systems, you immediately need special infrastructure to reduce paging when you deal with a pointer chasing language like Lisp applied to a application domain with GBs of memory.
• Lisp has a different surface syntax.
• Support for Functional Programming (Closures, ...) and Object-oriented Programming is still unusual in the operating systems we use. Standards are rare (CORBA, .net, ...) and limited.
• CLOS supports meta-level programming, multi-dispatch, extension of classes, little data hiding - making it mostly incompatible even in the basic paradigm with most Object-oriented Languages which are mostly following some kind of message-sending paradigm.
• No current OS uses Lisp's infrastructure as a model of organizing memory and/or data. There is no support from other communities for the Lisp infrastructure. (Exceptions are systems like Maxima, ...).
• There is little culture of static checks on the code level (by the compiler etc, ...). So you need to load software into a Lisp to inspect it or check it.

There is more to mention, but this should be sufficient to list.

The consequences are:

• most OS-level development tools cannot easily or usefully applied to Lisp code.
• the Lisp ideas about data layout are completely incompatible with OS-level ideas of data-layout. Lisp has its own ideas about data and thus needs to implement its own memory and data management. Almost none of the existing systems bought into that and tried to use Lisp's infrastructure.
• if Lisp wants to talk to the OS, it needs to use the OS datastructures or convert those into its own datastructures.

Lisp is not on its own with these 'problems'. Smalltalk, Prolog, Java, ... also have similar 'problems'.

The combination of these things automatically makes Lisp a very different infrastructure on any currently used system.

In the 'Lisp World' one should follow a few rules to be successful with software design:

• the best chance to survive have extensions that follow the spirit of Lisp (syntax, semantics, ...)
• See the basic Lisp as some kind of abstract machine and build on top.
• when in doubt design software to be dynamic (changeable at any time).
• when in doubt design software to be introspective
• when in doubt design software to be reflective

These rules are very different from what you see in many other software systems. There, for example, the compiler will compile it to static, non-reflective, non-evolvable machine code.

It is true that this different nature makes Lisp automatically a second class citizen on any current OS. But since Lisp is sufficiently different, its feature set also guarantees its survival. There are few comparable Languages/systems in the same niche (with some overlap from Smalltalk and Prolog).

SBCL 1.0

SBCL 1.0 is out. Release notes.

I'm not sure that the version number has much meaning other than the symbolic, but there is quite a bit of that symbolic weight. It's certainly a great success (though the comp.lang.lisp thread on the topic, 206 messages long at this point, indicates there is not complete consensus on this).