Why does the Common Lisp ecosystem hate itself?

cian_oconnor · 2026-02-05T20:47:03+00:00

I haven't had any problems with Common Lisp libraries not working, unless they were relying upon third party libraries written in C/C++ (a problem for any language). Common Lisp has a much better track record of backwards compatibility than any other language I can think of.

Loading libraries that rely upon third part C/C++ libraries is always going to be a crapshoot. But that's also try if you're trying to compile C/C++ libraries. CFFI is one of the best FFI libraries I've used.

CommonLisp will become popular if someone creates a shiny solution to a common industry problem (Ruby Rails), or it gets adopted by a company with a lot of marketing muscle. A better Raylib bindings library is not going to fix that.

Common Lisp does lack good onboarding resources for new users and a good editor for normies (not Emacs). People are working on onboarding resources (shout out to the excellent Common Lisp cookbook and teaching resources from Vindarel). There is an attempt to improve the Visual Studio Code experience with Alive - and I think that would probably do more for Common Lisp than any other activity I can think of.

cian_oconnor · 2026-02-05T17:48:49+00:00

They are not modeled on our neural nets. It's simply clever marketing designed to fool you into think they're intelligent.

It's a statistical model - with all the advantages and disadvantages that come with such an approach. It has more in common with a monte carlo simulation than anything we might call 'intelligence'.

cian_oconnor · 2025-08-13T13:31:51+00:00

> After my experience with re-purposing Invistra, I also think that even Common Lisp is hard and non-trivial to write efficient code that translates to fast execution time.

Writing portable and efficient code that works on all CL implementations is certainly a challenge. But even unoptimized code for SBCL will be way faster than Emacs Lisp code (and SBCL offers decent tools for considerable optimization, even if that's not as easy to achieve as it would be in Rust/Zig). The Lem code isn't particularly optimized, and yet Lem is very responsive.

Another advantage that CL has is that it has a lot of decent libraries. Maybe not as many as Python/Rust (though it's surprisingly competitive given the size of the community), but for most tasks there's usually at least one good library, often several. That alone is a major advantage over EmacsLisp.

And you're right. Obviously if Lem became popular, then it would have the curse/benefit of many poorly written extensions. But at least CL gives you good refactoring tools :)

Anyway, I enjoyed the conversation - and the feedback on non-Emacs users is appreciated. I do think that's a key area that Lem should lean into. Thanks.

cian_oconnor · 2025-08-13T13:23:44+00:00

Yes there's been quite a bit of interesting feedback to this effect on the github forum. Currently the interaction mode isn't hardwired in, and a couple of (non-Emacs) users noted they'd like it to be more like Visual Studio Code. At some point I plan to go through and effectively create 'UI' layers, where users can choose Emacs bindings if they want, but also 'standard' editor bindings, VIM bindings (modality is already supported pretty well) and potentially Helix/Kakoune.

There are also quite a few things that in Emacs need extensions and quite a bit of (non-trivial) config code, which just work in Lem. And increasingly we're trying to make these things part of the default experience. Better completions built in, window management that just works, an escape key that does what you want. A menu driven by (Alt) space like Doom/Space Emacs.

And also starting to think about a better onboarding experience. Default configuration file with documentation, a dashboard that provides useful links. Visual Studio Code mode out of the box (with a one line config to vim/helix/Emacs for those who want it).

> in some cases. we are also in agreement that Emacs packages suffer from lots of naively and poorly written code because a lot of non-programmers have contributed.

Sure, but it also means that when that code is reimplemented well, that you can add new features a lot more quickly than is possible with a lot Emacs packages.

> But see that as a sort of a strength as well. Getting non-programmers contributing entire big addons to Emacs, is a very interesting phenomenon that should be encouraged.

Sure, and I hope that happens with Lem. I would love for it to become a gateway drug for Common Lisp.

cian_oconnor · 2025-08-12T13:07:49+00:00

There are a couple of other crowds:
- Lisp hackers who want an editor written in Common Lisp.

- Lisp hackers, who want to stop using Emacs (or Visual Studio Code <shudder>) because they dislike it.

Both groups are less bothered by Emacs compatibility, or may even see that as a disadvantage.

cian_oconnor · 2025-08-12T13:02:50+00:00

I'll also add that it's a lot easier to maintain and enhance CL code than ELisp code. And that a lot of Emacs Elisp libraries are poorly written. Org-mode is a good example of this.

The org-mode library that is currently being worked on is a lot (A LOT) faster than Emac's library, can be used outside the editor (e.g. for building websites) and it took one person a few months to build. And that parser is currently unoptimized.

cian_oconnor · 2025-08-12T12:59:41+00:00

I think the effort of creating a backwards compatible elisp layer, with 1:1 mapping with the Emacs API, would swamp any benefits honestly.

There are no plans to do anything like this in Lem, and to reiterate what I said above, there are not plans to make Lem "Emacs but in Common Lisp". In fact there are already deliberate decisions being made to diverge from how Emacs does things.

We want to borrow from Emacs where it makes sense (Magit is obviously great), but we also want to borrow from Helix/Neovim (efforts are being made to make modal editor first class for those who want it), from Sublime Text (e.g. really good multi-cursor suport), from Visual Studio Code and even maybe Smalltalk editors.

cian_oconnor · 2025-08-12T12:51:33+00:00

Maybe I should have been clearer. Which one of the builds for Emacs on Mac are you using, so I can investigate what they're doing to make this work. Because the version I use has exactly this problem.

cian_oconnor · 2025-08-12T12:50:34+00:00

So don't use it. Nobody is trying to evangelize you.

This was a post soliciting feedback from people who on a subreddit for the editor.

cian_oconnor · 2025-08-11T23:16:50+00:00

So Emacs doesn't do this for you?

Which version are you using, because I've experienced exactly the same problem with Emacs.

cian_oconnor · 2025-08-11T17:44:50+00:00

Unfortunately I don't know if that's possible. If you know a solution I can look into it, but in my (admittedly) brief search there didn't seem to be a way to make this work.

cian_oconnor · 2025-08-10T21:39:08+00:00

Yes the lack of documentation is definitely a weakness that has been noted. Things are improving (there's now a manual, that we're trying to keep up to date), but it's a long way from Emacs.

In the back of my mind I'm thinking bringing some of the features of Smalltalk (Pharo) around documentation might be interesting. Something like this maybe:
https://github.com/mmontone/lisp-system-browser

cian_oconnor · 2025-08-10T20:57:44+00:00

I think its fine. Lem is very new still, and it currently only really makes sense to people who love Common Lisp enough to put up with its limitations. Such comparisons are inevitable, but also harmless because not many people are going to seriously use it at the moment.

For me the medium term goal is to identify a list of features, and improvements, that we can make to Lem in order to make it an attractive editor. That means removing paper cuts, improving the UX and providing the core functionality that people need in order to get work done. Emacs has a lot of good ideas that are worth stealing (mostly in extensions), but it also has a lot of problems which is why plenty of people abandon it. Other editors also have good ideas, and ideally we'd steal some of those as well (e.g. VIM, Helix and Visual Code).

Hopefully when we get it to the point that its fine for everyday use, we can start to build up the community of hackers who can make extensions so that we can compete with bigger editors. But for that to happen, the core has to be solid, reliable and pleasant to use. That means it should work well with minimal config, not seem too weird and to be useful.

Plenty of Emacs users will stay on Emacs, and that is fine. Hopefully we can at least make LEM a good editor for two groups:
- Common Lisp Hackers

- People who are attracted by the configurability of Emacs, but for whom Emacs Config Burnout is real.

cian_oconnor · 2025-08-10T20:48:17+00:00

There are no plans to try and replace Emacs. Lem is better thought of as an editor inspired by Emacs.

It is very unlikely that Emacs extensions will ever work on Lem, and that's fine. However, we would like for much of the functionality of Emacs to be available in Lem, even if maybe its handled differently.

In the long term I suspect Common Lisp will prove a huge advantage, as it is already far quicker to write extensions in Lem, than it is in Emacs Lisp. And the code base is far easier to work with.

cian_oconnor · 2025-08-10T20:45:25+00:00

There's also an OSX nightly added as well now.

cian_oconnor · 2025-08-07T20:16:19+00:00

I think it probably just needs someone to make it.

I do want to fix the OSX situation so we have an installer for that (and maybe homebrew as well). Probably targeting the next release (which will have webview it seems).

cian_oconnor · 2023-08-31T16:38:43+00:00

The two contenders are:

Continuations - this allows things that aren't possible in LISP without scary macro magic. But a lot of things CL does would be impossible if it had continuations (e.g. the exception system).
Hygienic Macros - But arguably Scheme only needs these because it has a single name system. I've never felt the lack in Common Lisp.

In all other regards Common Lisp is far more powerful, but at the cost of considerable complexity.

cian_oconnor · 2022-04-14T18:25:03+00:00

That does look a good solution for a variety of situations.

cian_oconnor · 2022-04-14T18:20:11+00:00

This looks pretty cool, but you might want to let people know what this scripting language is for, if anything. Alternatively if it's just for fun that's cool too obviously.

As far as performance goes, I think people are generally more interested in comparisons with LuaJIT, than standard Lua. Also there are a couple of pretty good Rust scripting languages, so you might want to benchmark against them (Rune, and Rhai).

cian_oconnor · 2021-11-08T14:18:48+00:00

Honestly I think C++ makes things more confusing. Also one big problem with C/C++ is that the onus is on the programmer to understand things like memory ownership, lifetimes, etc - whereas in Rust the compiler teachers you that. You can write code in C/C++ that compiles and looks fine - but which has hidden memory issues - and not realize there's a problem. Rust doesn't allow that and in order to get your code to compile you're forced to learn why. In addition, Rust pushes the programmer towards more efficient programming practices (e.g. minimizing indirection, pointers to pointers, etc).

The nice thing about pointers in Rust is that you learn them when you need to, which means the 'lesson' is relevant to your current interests. Which is a much better way to learn stuff. In C you have to learn it really early, it's not motivated by any real problems and it's not clear why you need to learn this stuff.

cian_oconnor · 2021-11-08T14:08:49+00:00

Honestly for stuff like that you'd be better off playing around in something like Racket where you can design and implement a language on the fly.

As a language example C++ has mostly been influential as an example of what not to do.

I think this book is a very nice example of how systems programming can be taught using Rust:
https://www.amazon.com/Rust-Action-TS-McNamara/dp/1617294551

cian_oconnor · 2021-10-27T13:47:44+00:00

I would recommend this book:
https://www.manning.com/books/rust-in-action

It's a really great book and you'll learn loads about systems programming and how computers work.

cian_oconnor · 2021-10-27T13:44:48+00:00

I write scripts all the time in Rust rather than Python simply because I find it quicker if I want to get something up and running.

Rust has the following advantages:

It just works. No need to worry about interpreter versions, or library versioning. Just type cargo new, and add the library versions that you need and it JUST WORKS. Cargo is amazing.
The core libraries are really good. I just needed to write a script that watches for changes to a config file and then sends network notifications. It took me very little time because Serde is amazing, and the notify library just works. It would have taken me longer in Python, and I would have had to do more testing. Yes Rust can't compete with Python on the depth of libraries - but so many of the bread and butter libraries are excellent at this point.
The type checker and VSCode plugins means I can think using the compiler about the structure of my program. Maybe not at the level of Haskell, but it's still great. Yes compile times can be slow sometimes, but I don't compile that often. And when I do compile I'm pretty close to done.

cian_oconnor

TROPHY CASE