Personaly i found abcl a bad experience.
Thoughts on ecl & clisp ?

sbcl works nice & fine. But i’t’s the only lisp implementation i know.
There are good books on racket-scheme & chez-cheme.
The only book i know for lisp is, “Common lisp , a gentle introduction to symbolic computing”.

  • aartaka@alien.topBEnglish
    1·
    1 year ago

    TL;DR: Use SBCL or CCL. Others—maybe, but likely in their own specific niches.

    I want to give more chances to implementations there are, so here’s my experience, in the order of preference:

    • SBCL is good. De-facto standard. The REPL experience is… not the best, but practical. Debugger loop is snappy, though.
    • CCL (Clozure Common Lisp) is extremely good for development: it is attentive to style, it has exhaustive type checks, it has a nice REPL (probably the best of open-source implementations, on par with Allegro) and a debugger with actually useful stack traces.
    • ECL is embeddable, and that’s its biggest value proposition: you can run it anywhere C runs and you can interact with C-based software easily. Beyond this platform-friendliness, ECL has reasonable code optimization abilities and a practical REPL.
    • ABCL is useful if you interface with JVM. So if you need to work with Java in Lisp, it’s either Clojure or ABCL. Implementation and REPL experience is somewhat simplistic, but let’s give it a chance.
    • CLISP is abandonware, even though the riches of the golden age when it was researched and worked on are still there.
    • Allegro is proprietary, which sucks. Given that it’s proprietary, it doesn’t have as much contributors as, for instance, SBCL. So it actually is worse than open-source impls. But it has a nice inspirational REPL. If you don’t need a commercial support license for a huge company, then you likely don’t need Allegro.

    I haven’t tried Clasp, Corman, CMUCL, and LispWorks. So no review for them. I tried GCL, but let’s not talk about that.

    • love5an@alien.topBEnglish
      1·
      1 year ago

      It is “SBCL or proprietary” nowadays. LW and ACL are fine but are pricy and well, proprietary.

      CCL is all but dead.

      ECL has a kind of limited niche, and is not as advanced as SBCL(e.g.: MOP). Same goes for ABCL. Also, ABCL is kind of slow.

      Clasp is somewhat interesting, but it also has a limited niche (C++ interop) and is also not as advanced as SBCL.

      GNU implementations are dead(GCL, CLISP)

      Everything else is as dead as GNU implementations.

      • aartaka@alien.topBEnglish
        1·
        1 year ago

        Yeah, that sums it well enough. I pin my hopes on ECL and Clasp because of portability and active development.

      • downtown-quasi-moody@alien.topBEnglish
        1·
        1 year ago

        Can I ask what you mean by CLISP being dead? The last stable release was 10y ago yes, but development continues to this day and beta releases are available. Nixpkgs actually ships a beta version by default now.

        ​

        I maintain a Nix scope with hundreds of Common Lisp packages and I am actually about to merge a dev branch that introduces CLISP support for all packages & their tests; it holds its own pretty well: https://github.com/hraban/cl-nix-lite/tree/clisp. see the list of all packages in the lisp-packages-lite.nix file).

        ​

        CLISP development: https://gitlab.com/gnu-clisp/clisp

        • love5an@alien.topBEnglish
          1·
          1 year ago

          Well, I was judging by its official page and Sourceforge activity, which seems negligible. However, Gitlab also does not seem very active (6 commits this year, despite lots of open bugs). The development is almost stalled. It is on life support, at best.

      • CommonLisp4ever@alien.topBEnglish
        1·
        1 year ago

        Without additional packages, the sbcl repl doesn’t support history nor sensible editing.

        The best REPL is Emacs/Sly, anyways.

    • arthurno1@alien.topBEnglish
      1·
      1 year ago

      CLISP is abandonware, even though the riches of the golden age when it was researched and worked on are still there

      I don’t know how much they consider it complete and how much they just don’t work on it, but there are some updates from time to time; I see the creator Bruno is pushing fixes from time to time.

      I tried GCL, but let’s not talk about that.

      :-) I would be interested to hear the experience. I am aware of it, but I haven’t had time to try it myself. They also seem to be on very sporadic development.

      I personally haven’t tried Clasp, CMUCL, CLisp and GCL yet; I just don’t have time. It takes time to try everything properly, build it etc, so I am currently just using sbcl; but I would be interested to know how other implementations compare in terms of completeness, extras they offer, performance, correctness etc. I would even watch a YT video if some YouTuber was interested in making a review wink wink you know who you are :).

    • lispm@alien.topBEnglish
      1·
      1 year ago

      CCL is mostly only on life support. The native port to the Apple Silicon Macs isn’t under way. CCL isn’t making any progress.

      Allegro … So it actually is worse than open-source impls.

      I doubt that this is generally the case.

      • aartaka@alien.topBEnglish
        1·
        1 year ago

        CCL is mostly only on life support. The native port to the Apple Silicon Macs isn’t under way. CCL isn’t making any progress.

        Didn’t know it’s that bad 😢 A shame—CCL is a nice piece of work.

        This is the index of the Allegro CL documentation: https://franz.com/support/documentation/10.1/doc/contents.htm

        I’ve been overly generic, I guess. What I meant was answering a (supposed) OP’s request for raw implementation usability. Which is REPL, introspection facilities, SLIME/SLY integration. Allegro is not perfect when viewed from this perspective. Proprietary implementation makes it hard to inspect what’s going on in the image and optimize the code comprehensively:

        • disassemble is useless.

        • Inspection is locked to what they provide—even SLIME/SLY merely uses the implementation-provided function for inspected parts. On other implementations, SLIME/SLY provides a lot of auxiliary info that implementation doesn’t explicitly provides.

        • In general, you can’t override the useful parts of the REPL easily: defining new REPL commands is a pain, building GUI tools inspecting the image is either parsing the unreliable raw output of Allegro-provided functions or giving up and using what they provide.

        Given that OP likely asked about the general development experience, and that I’ve done a lot of work with basic text REPL interaction on all the implementations I listed above—Allegro is not the ideal basis, especially for learning.

        The documentation and the additional products they provide is good, but that’s beyond the basics that OP is probably interested in.

        I don’t know many open source Common Lisp implementations on this level.

        Fair, I’ve been overly generic too. To me, the basic inspection and interaction is smoother at least on SBCL and CCL, which is, like, two out of five? somewhat maintained implementations.

        • lispm@alien.topBEnglish
          1·
          1 year ago

          Proprietary implementation makes it hard to inspect what’s going on in the image and optimize the code comprehensively

          If I were a paying Franz customer and I would be interested in SLIME/SLY improvements, I would kindly ask them to provide it. Maybe they would then just do it or ask the customer to pay for it. That’s what technical support is for.

          Second: as a Franz customer one could get the source code for much of the product. I’m not a customer, but I guess this possibility still exists.

          Allegro is not the ideal basis, especially for learning

          I think it can actually be the opposite. Among new Lisp users GNU Emacs is often cited as a hurdle.

          Allegro CL comes with an GUI based IDE on Linux, Windows, and Web browsers. This makes it possible to use it without GNU Emacs + SLIME/SLY. I consider that to be a feature. The IDE of Allegro CL has a bunch of features: https://franz.com/support/documentation/10.1/doc/cgide.htm#menus-dialogs-1

          Best: the stuff is written all in Allegro CL itself and can be reused.

          • aartaka@alien.topBEnglish
            1·
            1 year ago

            Oh wait, it really ships with a GUI-based IDE… I’m convinced—Allegro is good, especially when paid. When talking about free version, my non-introspection comments still apply, but they are kind of implied for a free version of proprietary product.

    • Soupeeee@alien.topBEnglish
      1·
      1 year ago

      CMUCL is basically a worse version of SBCL. SBCL is a fork of CMUCL with the goal of being more maintainable. Some things have been backported between the two, and there maybe a few things present in CMUCL that aren’t in SBCL, but I think most of the interesting things have been added back in.

      Clasp is to C++ like what ABCL is to Java. I haven’t done much more that fire it up to see if it would run, but it’s C++ integration looks fantastic.

      • lispm@alien.topBEnglish
        1·
        1 year ago

        CMUCL is also way behind it platform support. CMUCL is mostly limited to being a 32bit application (IIRC). SBCL OTOH supports various 64bit platforms, incl. ARM64 on Linux and macOS.