That's awesome, thank you. How do you know it, is there a reference on the net somewhere?

Thank you, TLS should be fine now. (fixed ±12 hours ago)

JetBrains IDE plugin for Common Lisp: https://github.com/Enerccio/SLT (I'm sure you saw it before and I don't know how polish it is, and I'm pretty sure it has less features than Emacs&SLIME, yet, but I must link it for reference. Because yes, before 2023 we could complain there were no JetBrains IDE plugin for Common Lisp, since 2023, we have one.)

We all can google. Have you tried to install the plugin? It doesn't support the current version of the IDE and as the last commit was 8 months ago there is no hope it will get such a support soon.

TBH no people don't google (what they don't expect to see), repetition and showing links is necessary. I hadn't followed along. Hope it will get contributors.

I mean the following with all due respect—and I have a lot of respect for your many efforts and contributions—but it will sound a little blunt, especially as a written comment.

"We have one," no, this is a consistent problem with people who evangelize Lisp. We have had "IDEs" for decades. Most of them, except the couple commercially supported ones, were "experimental", "incomplete", "buggy", etc. This includes the one you link here.

Are these projects valuable as a starting point for other hackers to join in and help? Sure, maybe. Are they helpful for a new programmer? Almost always the answer has been "no". I have first-hand experience subjecting a programmer to one of these tools, and I myself getting incredibly frustrated at how broken it is. Imagine somebody completely new.

You in particular love to advertise these different projects as a form of Lisp evangelism. Advertising the projects is great—I hope they attract helpers—but I think your language around them is deceiving.

> Because yes, before 2023 we could complain there were no JetBrains IDE plugin for Common Lisp, since 2023, we have one.

"We have one" in the absolutely most rudimentary interpretation of that phrase. What we don't have is a working JetBrains Common Lisp IDE suitable for production use.

In order to try to promote a realistic view as to why Lisp doesn't attract more programmers in 2026, I myself will continue to point out Lisp's highly substandard tooling offering until there's an actual product that works. Any Joe can spend a weekend making a 1/2 baked, proof of concept IDE. Even more so now with all the AI vibecoding tools we have at our disposal. It takes much more to make something that checks all the boxes.

ACK, allright. I just want to point people to stuff. Create emulation. Show that the ecosystem is evolving -in the right direction even, maybe. That we are not doomed to stay with Emacs&SLIME. A few years ago, we didn't have SLIMA, the VSCode plugin, Jupyter and JupyterLite kernels, the very useful ICL, nor CLOG, nor these incomplete IDE attempts (Intellij, Sublime…). How good is the new Zed plugin BTW? https://github.com/etyurkin/zed-cl

(I'm not even evangelizing in these comments so thanks for the feedback I guess!)

New projects are making the newcomer experience easier:

- ICL https://github.com/atgreen/icl/ a full featured REPL in the terminal and the browser.

- JSCL's playground 100% in the browser https://wiki3-ai.github.io/jscl-kernel/ (very new)

- constantly new editor plugins. A new one: Zed https://github.com/etyurkin/zed-cl (all editors, for readers, including VSCode, Pulsar etc: https://lispcookbook.github.io/cl-cookbook/editor-support.ht... Those editors appeared in recent years. So, I see a good trend in the ecosystem).

There's a new one, pretty good, resembling Python/Julia syntax, check it out! https://moonli-lang.github.io/

    defun multiply-thrice(x):
      print(x * x * x)
    end

    multiply-thrice(23)

> so many shortcomings and missing features

I suggest to have a look at CIEL: https://github.com/ciel-lang/CIEL/

-> CL, with batteries out of the box: http, json, csv, DB, functional data structures, regexp, pattern matching, missing docstrings, missing functions, easy script runner…

and to Epsilon: https://github.com/jbouwman/epsilon/

> Epsilon is a Lisp programming environment built using SBCL that provides functional data structures and some encoding, cryptographic hashing and network programming capabilities.

Recently added in Lem: tree-sitter for JSON, YAML, Nix, Markdown, WAT; new language modes: Clojure, Perl, Kotlin, Zig (with LSP); git-gutter mode.

Lem has a (quite simple still) Git/hg/fossil interactive mode (interactive rebase is there but no reword for instance) and org-mode support is coming (https://github.com/mahmoodsh36/organ-mode).

Lem now is ncurses + webview (+ the non-longer maintained SDL2 backend) and it has daily multi-platform binaries. Try it out!

https://lem-project.github.io/

I tried the latest nightly release AppImage on Fedora 43 and got a nice undefined symbol error:

    /usr/lib64/gio/modules/libdconfsettings.so: undefined symbol: g_assertion_message_cmpint
    Failed to load module: /usr/lib64/gio/modules/libdconfsettings.so
    /usr/lib64/gvfs/libgvfscommon.so: undefined symbol: g_task_set_static_name
    Failed to load module: /usr/lib64/gio/modules/libgvfsdbus.so

So I tried out the container version with podman and that worked. I am familiar with Emacs, so some things were natural to me. I like Lem quite a bit. But to really drive with it, I need:

    - Solid LSP support
    - Project scoped buffer switching/searching
    - Great vim keybinding support (this seems to have improved since last I tried lem years ago)
    - Tree-sitter support for the languages I care about.

According to the website, LSP support is still a WIP. I didn't want to go through the hassle of testing it out in the docker container. From what I can tell, there is no project scoping for buffers, but I might be wrong.

All in all, a big improvement from a few years ago when I last tried it!

Hello, yes there's project scoping: https://lem-project.github.io/usage/usage/#project-commands (added by yours truly, which was easy thanks to Lem's quality code base). I find the vim layer excellent, you can open an issue if you find obvious things missing.

The same day, after this post, SBCL's main developer made reduce faster (https://www.reddit.com/r/lisp/comments/1pmip8o/fast_sequence...). Let's see on the next SBCL release what the final results are.

Stas is a machine. Almost every single day he's in the sources making improvements. I joined the sbcl-commit list recently and the project is far more active and cared for than I had originally suspected.

SBCL is a treasure. I really enjoy writing lisp, I just wish the library ecosystem was a little more mature.

I still use it whenever I can

It has only been 68 years, give it a little more time.

Differences I see with cl-repl (https://github.com/lisp-maintainers/cl-repl):

- icl doesn't have an interactive debugger, you ask for the backtrace with ,bt. cl-repl has one (less feature complete than Slime). I actually like the lack of a debugger for newcomers.

- icl: does auto-indentation right

- cl-repl: has an %edit command to launch an editor and load the file content on close.

- icl: better, prettier autocompletion with a drop-down. cl-repl is based on readline.

- icl: based on Slime's backend, so you can connect to another running image.

- cl-repl: has a ! shortcut to execute a shell command.

- cl-repl might be faster to launch.

big thanks to atgreen for all the nice projects!

Thanks, vinderal. Since you wrote this the other day, I've improved the auto-completion so it is more context-aware. For instance, it will auto-complete using your filesystem when it is reasonably sure that you are trying to reference a filename. There's also a new interactive object inspector TUI, and a super-experimental `,explain` command. `,explain` will fire up gemini/claude cli to have it explain the last command/result/error. It provides temporary access to an icl mcp service so the AI can use tools for read-only access to your running lisp image.

The other way round, a Haskell on top of a Lisp, in production today: https://github.com/coalton-lang/coalton/

> Coalton is an efficient, statically typed functional programming language that supercharges Common Lisp.

Presentation this year on the ELS: https://www.youtube.com/watch?v=of92m4XNgrM

I'm not sure I'd say this is "the other way around"; Coalton strives to implement Haskell or ML-adjacent semantics (in the type system, for example) with Lisp syntax. "With" here meaning that it is both implemented in and written with Lisp syntax.

Edit: I think I see what you mean now. Lisp backend vs Haskell backend.

Anyway, Coalton is a joy to use and IMO a breath of fresh air in CL. It's quite easy start using as a library; go all-in or only use it in specific parts of the code. It's great to be able to choose between (or intermix)the flexibility of CL and the guarantees of a statically typed language (as well as some nice performance boosts with arguably less work). Some aspects are still young (some of the standard library, ecosystem, editor support), but it's quite thoughtfully crafted and I'm excited to see where it goes.

>Coalton strives to implement Haskell or ML-adjacent semantics (in the type system, for example) with Lisp syntax. "With" here meaning that it is both implemented in and written with Lisp syntax.

Not exactly. Coalton brings ML-style strong typing to Common Lisp. But Coalton code is also Lisp code.

The backend, thus, is Common Lisp, and it is available at all times, thus leveraging all its power.

I think I meant the same thing, but you said it much more clearly, thanks!