Comment by flavio81 | Hacker News Reader

Comment by flavio81 | Hacker News Reader

Parent Full thread

>The main issue people have with the book is that it uses CLISP-specific code in a few places.

This makes sense for a tutorial book, since CLISP is easy to install, very small to download (compared to SBCL), and is a fully featured (ANSI compliant) implementation. So i don't think it was a mistake to choose CLISP.

The recommendation in #lisp for SBCL over CLISP might be because SBCL is nicer to the programmer, offering more features. Also, code runs very fast under SBCL; although i suspect that CLISP compiles code faster.

(If any is interested, here is a quick overview on some of the Lisp implementations available and their salient features. (Most implementations are free)

    ECL - Embeddable Common Lisp
        allows you to compile Lisp into any 
        other system by compiling to C

    SBCL - Steel Bank Common Lisp
        Produces very fast code, 
        allows static type checking and other niceties
        a fork from the CMU CL impl.

    CLISP
        Small, easy to install and use, 
        includes readline REPL and X11 features

    ABCL - Armed Bear Common Lisp
        Allows you to run Lisp under the Java JVM 
        and call Java code, or call Lisp code from Java.

    CLASP 
        Compiles Lisp to the LLVM, provides C++ interop

    ACL - Allegro Common Lisp
        Commercial Lisp, fast, feature rich
        includes a Prolog implementation, CLIM GUI
        and other nice stuff.

    LispWorks
        Commercial Lisp, fast, feature rich,
        includes an IDE, Java Interface, 
        and CLIM 2.0 implementation, more features. 

    ParenScript
        This is a small subset of CL that gets translated
        (in the server) to javascript

    JSCL
        A Lisp implementation that runs under Javascript,
        providing a REPL and Lisp interpretation on the
        browser, for a subset of the CL language.
)

I'd add one more very popular implementation:

  CCL - Clozure CL
     Produces fast native code; compiles faster
     than SBCL. Also has some MacOS-specific goodies.

People sometimes use both CCL and SBCL at the same time, to have faster compiling during development via CCL and then better runtime performance of the released version via SBCL.

I used to use CCL for hobby gamedev back when SBCL had some troubles on Windows (they're gone now); now I only use it on Raspberry Pi (AFAIK SBCL couldn't utilize multiple cores on ARMs last time I checked (which was a years ago)).

Thanks TeMPOraL! I'll try CCL then!

It is also because CLISP is unmaintaned. But the only implementation dependant code I remember is the socket code.

But CLISP wasn't unmaintaned when the book was written más its default REPL is much better than other implementations. It was a good choice at the time.

> CLISP is unmaintaned

AFAIK, it is not really unmaintained, the developers just haven't done a release in years. When I fire up CLisp on openSUSE Tubmbleweed (their rolling release distro), it says

    Welcome to GNU CLISP 2.49.60+ (2017-06-25) <http://clisp.org/>

That would make me think that development might have slowed down, but not stopped.

Yet, if you visit that URL, you are greeted with :

    Current version:	2.49 (2010-07-07)

Seems like the patch level on openSUSE is provided by the package maintainer, not CLISP. It looks like Debian Wheezy is at "2.49-8.1", Ubuntu Xenial is at "2.49-9ubuntu1", FreeBSD Ports is at "2.49_6", but also marked deprecated/expired as of 2014.

I'd venture that the maintainer is applying patches to the upstream source to keep it running on the OSes when they update ABIs, etc.

The most recent commit to the source tree (https://sourceforge.net/p/clisp/clisp/ci/tip/tree/) was today.

Not sure how much that is worth - with no release in seven years, I would guess there is not much going on. But it is still more than nothing.

CLASP is for me the most exciting CL implementation right now. Compilation to the LLVM is a huge advantage.

Sadly, it's a one-man thing. And CL seems quite stagnant.

I wish one implementation triumphed over the others, and CL progressed beyond its ANSI standard.

Clojure has many interesting things. So does Racket. The Lisp landscape is too fragmented. And thus libraries are a huge problem.

>I wish one implementation triumphed over the others

That would be terrible. Part of the nice things of CL is that you can choose the implementation according to what you need. For example ECL if you want to embed your lisp code with C code. ABCL if you really need to call lots of Java libs (or have Java code call your Lisp code easily), and so on. We're talking about mature, proven, tested implementations.

If one implementation triumphed over others, over time we'd be in a position similar to, say, Python or Clojure, where there is only one or two implementations, besides some experimental implementations, and nothing else.

Something that needs to be mentioned is that CL is truly standardized; if you have a code written in Common Lisp, chances are it will compile straight away on most of the implementations (ECL, ABCL, SBCL, etc), with no change needed. So having many implementations does not mean there is any kind of fragmentation in the language.

>and CL progressed beyond its ANSI standard.

CL is one of the most extensible languages out there, so it has already progressed way beyond the ANSI standard. The standard doesn't need modification to support new things. There are already many libraries giving you things that are not in the standard (like sockets or threads) but in a portable and standarized way.

But the whole idea, to your own point, is that there are lisps everywhere, compiling to everything and each having specialized additional features for the local needs, yet the ansi core remains intact, so everyone can use every one of those lisps (if they really are lisps...I’m looking at you, clojure!) [ED: I’m good with RSR5 too ... Jerry Sussman himself calls scheme a Lisp!]

> Compilation to the LLVM is a huge advantage

Is it? Advantage over what?

> And CL seems quite stagnant

That's good then, since he can better catch up.

> Sadly, it's a one-man thing.

He can always reuse code from other implementations. Though I agree that it is too much work for a single person to create a quality implementation of Common Lisp.

Problem seems to be that there is not enough interest in another implementation based on an un-explorered infrastructure (LLVM).

> CL progressed beyond its ANSI standard

It has. In implementations and libraries.

Reply on news.ycombinator.com