Extensibility: the "100% Lisp" Fallacy
Key topics
The debate around the "100% Lisp" ideal sparks a lively discussion on the merits and limitations of extensibility in programming languages, particularly in the context of Common Lisp and its implementations. Some commenters, like xvilka, argue that the Common Lisp standard is due for an uplift, citing shortcomings and missing features, while others, like metroholografix, counter that the CL specification's breadth is a valuable asset. Meanwhile, vindarel showcases Lem, an extensible editor with a growing list of supported languages, highlighting the practical applications of Lisp-like extensibility. As the conversation unfolds, it becomes clear that opinions on the "right" approach to Lisp extensibility are sharply divided.
Snapshot generated from the HN discussion
Discussion Activity
Moderate engagementFirst comment
1h
Peak period
8
0-6h
Avg / period
4.5
Based on 18 loaded comments
Key moments
- 01Story posted
Jan 1, 2026 at 8:36 PM EST
8 days ago
Step 01 - 02First comment
Jan 1, 2026 at 10:05 PM EST
1h after posting
Step 02 - 03Peak activity
8 comments in 0-6h
Hottest window of the conversation
Step 03 - 04Latest activity
Jan 5, 2026 at 11:05 AM EST
4d ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
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/
All in all, a big improvement from a few years ago when I last tried it!
[1] https://github.com/blakemcbride/common-lisp-3
[2] https://github.com/lassik/compact-lisp
> 1. The function and variable namespaces have been collapsed into a single namespace.
Lisp-N, package system and homoiconic macro is a local optimum (IMO practically much better than Scheme, but I digress) for variable capture issue in metaprogramming. Now it's saying let's bring back the footguns and also you have to write lst instead of list. Please, no.
> 2. ...adds a layer on top of CLOS
How about a library? Why a new standard?
> 3. Common Lisp 3 supports case-sensitive symbols.
This I can relate.
> 4. Common Lisp 3 supports native threads. > 5. Common Lisp 3 supports tail recursion elimination.
Practically not a problem for today's CL. There's nothing to fix.
> Meanwhile proper typing should be introduced out of the box, like in Coalton[3], for example.
Are you saying Coalton as an embedded language should be introduced out of the box? I'm afraid it may quickly earn similar reputation as LOOP and FORMAT. Or are you saying the whole language should adopt Coalton-like typed semantics? Then I don't think it's even possible for large part of the language, especially when you take interactivity into account. What happens when a function gets redefined with different type? Worse, how about CHANGE-CLASS and UPDATE-INSTANCE-FOR-REDEFINED-CLASS?
> Also, pattern matching should be the part of the language, not some external library [4].
Why not? Common Lisp as a living and extensible language now evolves by adopting de-facto standard (trivia for pattern matching, bt for native threads, usocket for network, ASDF for build system, etc). Why need a committee or other form of authority to prescribe what everyone gets to use when we have a maximally democratic process?
Not the whole language as is but proper algebraic types at least. Just like most modern languages do.
> Why not? Common Lisp as a living and extensible language now evolves by adopting de-facto standard (trivia for pattern matching, bt for native threads, usocket for network, ASDF for build system, etc). Why need a committee or other form of authority to prescribe what everyone gets to use when we have a maximally democratic process?
Totally a valid point but then something like Compact Lisp proposal to strip the language to the bare minimum and extract everything out in libraries would make way more sense than the huge and only half-used CL standard we have now.
In the same way that non-hygienic macros in a Lisp-2 with a CL-style package system are a local optimum, many non-obvious design choices in the Common Lisp type system and CLOS make SLIME "just work" in almost every case.
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.
> you will want to support font fallback, input methods and screen readers, all of which require interacting with platform specific APIs and are thus much less customizable
May I ask the heretical question why of these two situations:
(a) you have one editor that makes compromises between extensibility and accessibility
(b) you have one non-accessible editor that goes all-in on extensibility, and one not-fully customizable editor that goes all-in on accessibility
one would prefer (a) over (b)? Situation (a) sounds like strictly more total effort for a worse outcome, as you have one much more complex system that tries to navigate both purposes.
We also don’t want non-disabled people to be treated like they are disabled (to not use other words). And no, gray on gray is not accesibility, Narrator is not accesibility, dumbing down things is not accesibility.
Glad we settled that.