Extensibility: The "100% Lisp" Fallacy • Hacker News Board

Re: Extensibility: The "100% Lisp" Fallacy

#11

Post by metroholografix » Fri, Jan 02, 2026, 7:43 AM UTC

xvilka wrote: post #10

kscarlet wrote: post #9

Earlier quoted context omitted.

I don't find any good idea in [1]. > 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 t…

> Are you saying Coalton as an embedded language should be introduced out of the box? 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 othe…

If you want Scheme, go use Scheme because these are not arguments for Common Lisp. There is tons of value in the CL specification being this big and I'm happy I can still run code I wrote more than 25 years ago (or third party code written more than 50 years ago) without any issues.

Generally, contemporary folks that propose improvements to the CL spec tend to be misinformed / misguided and/or lacking experience to realize why their proposed improvements are bad ideas.

Re: Extensibility: The "100% Lisp" Fallacy

#12

Post by codeflo » Fri, Jan 02, 2026, 8:30 AM UTC

The author mentions in the article text (and re-emphasizes in a footnote) that you will want to use platform-specific APIs for improved accessibility even when this limits extensibility:

> 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.

Re: Extensibility: The "100% Lisp" Fallacy

#13

Post by remexre » Fri, Jan 02, 2026, 10:39 AM UTC

xvilka wrote: post #10

kscarlet wrote: post #9

Earlier quoted context omitted.

I don't find any good idea in [1]. > 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 t…

> Are you saying Coalton as an embedded language should be introduced out of the box? 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 othe…

How would algebraic types work with SLIME? If I remove a constructor from my algebraic type, what happens to values of that type that are built with that constructor that're stored in globals?

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.

Re: Extensibility: The "100% Lisp" Fallacy

#14

Post by kscarlet » Fri, Jan 02, 2026, 11:20 AM UTC

remexre wrote: post #13

xvilka wrote: post #10

Earlier quoted context omitted.

> Are you saying Coalton as an embedded language should be introduced out of the box? 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 othe…

How would algebraic types work with SLIME? If I remove a constructor from my algebraic type, what happens to values of that type that are built with that constructor that're stored in globals? 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 guess this case is workable similar to struct redefintion. There can be a condition and a CONTINUE restart, which makes instances of the removed constructor obsolete.

Re: Extensibility: The "100% Lisp" Fallacy

#15

Post by frou_dh » Fri, Jan 02, 2026, 11:25 AM UTC

What I got from this is that the author doesn't like the term Extensible being used for situations that don't follow good software engineering practices. Maybe the term Hackable is less offensive and implies dirtiness being okay.

Re: Extensibility: The "100% Lisp" Fallacy

#16

Post by vindarel » Fri, Jan 02, 2026, 11:46 AM UTC

xedrac wrote: post #6

vindarel wrote: post #3

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…

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 vers…

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.

Re: Extensibility: The "100% Lisp" Fallacy

#17

Post by vindarel » Fri, Jan 02, 2026, 11:54 AM UTC

xvilka wrote: post #8

Common Lisp standard (and its implementations) really needs an uplift to shine. There are so many shortcomings and missing features in it that listing them here would take a lot of space. Instead, I will point to some proposals like Common Lisp 3[1] and Compact Lisp[2]. Meanwhile proper typing should be introduced out of the box, like in Coalton[3], for example. Also, pattern matching should be the part of the langua…

> 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.

Re: Extensibility: The "100% Lisp" Fallacy

#18

Post by InfiniteRand » Fri, Jan 02, 2026, 1:08 PM UTC

codeflo wrote: post #12

The author mentions in the article text (and re-emphasizes in a footnote) that you will want to use platform-specific APIs for improved accessibility even when this limits extensibility: > 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…

It would depend on your accessibility needs, if you only need the apis included in a, then a would be a better option

Re: Extensibility: The "100% Lisp" Fallacy

#19

Post by jockm » Fri, Jan 02, 2026, 3:26 PM UTC

codeflo wrote: post #12

The author mentions in the article text (and re-emphasizes in a footnote) that you will want to use platform-specific APIs for improved accessibility even when this limits extensibility: > 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…

Because accessibility should be front of mind for all apps. We don’t want disabled people to be treated like an afterthought or only using specialty apps. Anyone can become disabled and need these features, either temporarily or permanently and shouldn’t have to change their entire tool chain to adapt

Re: Extensibility: The "100% Lisp" Fallacy

#20

Post by hulitu » Mon, Jan 05, 2026, 4:05 PM UTC

jockm wrote: post #19

codeflo wrote: post #12

The author mentions in the article text (and re-emphasizes in a footnote) that you will want to use platform-specific APIs for improved accessibility even when this limits extensibility: > 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…

Because accessibility should be front of mind for all apps. We don’t want disabled people to be treated like an afterthought or only using specialty apps. Anyone can become disabled and need these features, either temporarily or permanently and shouldn’t have to change their entire tool chain to adapt

> We don’t want disabled people to be treated like an afterthought or only using specialty apps.

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.