Emacs Lisp's future (was: Guile emacs thread (again))

[Nic Ferrier <nferrier@ferrier.me.uk>]

Stefan Monnier wrote:

> 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.
> - Lack of some features, most notably FFI and concurrency.
> - Lack of manpower.
>
> This last point is for me the strongest motivation to try and move to
> some other system, where we could use other people's work.

I don't see that this is going to happen though. Emacs is an unusual
system. Moving the extension language to another community is just going
to cause more arguing along the lines of "this is how X lang does it" vs
"but we're Emacs and don't want to do it like that".

My view is we should improve the contribution process to get more
manpower for elisp. We have been doing that as a community. As a
reminder we have:

- adopted packaging allowing many more people to contribute pure elisp
- accepted a move to the most commonly used support tools (git, etc...)
- started to talk about changing the documentation format to a more
  common format

I see a new spirit of openness and willingness to change in the Emacs
community and it's really great.

I would implore you, my fellow emacs hackers, not to make too hasty a
decision on platform. Guile-Emacs may be cool, but if we can increase
developer diversity in Emacs through git and so on (I for one will be
contributing to the core thanks to this) then we may get all the
advantages of the Guile VM without having to go to Guile.

I'm sure there is more that we could do to get more man and woman
power. I hope that we consider those things as well as techy projects
like switching to Guile's VM.


Nic