Re: Shrinking the C core

[chad <yandros@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1885 bytes --]

Now that we're in -tangets (thanks for doing that, btw)...

On Tue, Sep 12, 2023 at 7:57 AM Eli Zaretskii <eliz@gnu.org> wrote:

> [...] And don't be afraid of losing some of the applications and the
> documentation -- these should be the least of your worries. [...]
>

My own opinion has come around to match Eli's (far more relevant/expert) on
this topic, but in case it helps anyone else: I think this reflexive desire
to keep a strong hold on all the existing elisp comes from the long line of
emacs clones like Edwin, Hemlock, climacs, Alpha, and a long list of less
well-known alternatives. I "lived through" several of these, and the sense
I got from every one I actually tried was that people eventually fell back
to the "real thing" emacs, largely because it worked (well enough?) and
already had some facilities that were missing in the putative replacement.

summary: I think it's hard to unlearn this lesson from history

It's entirely possible that the shift of "typical computing" towards
massively multi-core distributed etc. is the final straw, or at least the
high bar that a massively-shared-state-lisp-machine can't vault -- while
still being good enough to cross most of the moats we see in everyday
usage. It's also possible that there's some adaptation that will arise,
perhaps along the lines of how web workers/service worker threads interact
with the DOM in the modern browser, that keeps Emacs going even longer. I
remember the days when "Yeah, that will happen shortly after the release of
Emacs 21" was the in-joke for porcine aeronautics, and we just saw Emacs 29
released, so: it could happen.

I do think that a very early step needs to be "figure out how to handle
concurrent analysis and editing across multiple cores and perhaps
machines", but that probably just reflects a bunch of my personal interests.

~Chad

[-- Attachment #2: Type: text/html, Size: 2366 bytes --]