Re: Emacs Lisp's future

[phillip.lord@newcastle.ac.uk (Phillip Lord)]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
> First, of course we can keep on evolving Elisp on its own.  This has
> worked OK for the last 30 years, so it's not such a terrible choice.
> The main problems I see with that:
> - Elisp is slow and as CPUs aren't getting faster, its slowness makes itself
>   noticed more often.

I've been going through some 10 year old elisp of mine recently. The
thing that surprises me is how many times I mention performance in it. I
rarely worry about this these days. Elisp performance as is seems rarely
an issue.

Where I would say that there is an issue is that too much of Emacs is
written in C. Having a faster elisp would allow moving more into lisp
and thus having more of Emacs extensible dynamically.

> - Lack of some features, most notably FFI and concurrency.
> - Lack of manpower.

I'd add a fourth. People who want to extend Emacs for their own purposes
have to learn it. Having JS extensibility would be an enourmous win.


> So if we go for Guile-Emacs, we'll be stuck with Guile, i.e. we'd
> have (old and new) packages that use Elisp, new packages that use
> Scheme, maybe yet other new packages that use, say, Javascript (or some
> other language support by Guile).  That would make the work of Emacs
> (and GNU ELPA) maintenance harder.

Thinking of Emacs as an entire ecosystem, most of Emacs is already
maintained independently from either Emacs core or GNU ELPA. For common
languages (like Javascript), the maintaince might be ligtened because
more people would be available.

Of course, it is worth mentioning that some of the big advantages from a
language like Javascript come from the implementation. A guile based
implementation wouldn't benefit from the intensive JS VM development
that has happend over the years.

Phil