Re: Why is Elisp slow?

[Stefan Monnier]

> Inter-language interaction (which is one of the strong features in
> Guile out of the box)

That's fairly abstract (details matter: e.g. how are you going to use
macros like `define-minor-mode` from non-Elisp languages?). 

Also while I much prefer Scheme to Elisp (or Common-Lisp for that
matter), I'm not looking forward to maintaining Emacs packages in two
(and more) different languages, and other maintainers are probably
imagining such maintenance nightmare with a lot more dread than I.

So again: what are the advantages?

>From that point of view, moving Emacs to a Common-Lisp implementation
would make more sense, since there is a chance we can *replace* Elisp
with Common-Lisp in the long-run, rather than adding another language on
the side.

> and native compilation.

That's irrelevant.  I think you mean "efficiency" or something like that.
But that presumes that Elisp-on-Guile is indeed more efficient than
Elisp-on-Emacs.  Is there actual evidence that this is the case?

Also "efficiency" is broad: there's the execution time of some
benchmarks, of course, but there's also the startup time, the VM size,
the heap size, the GC interruptions, the time to load a big package
(e.g. org-mode), ...

Guile would hopefully win on some of those, but by how much?
And how much worse does it make the others?

> Plus some people taking care of the compiler/interpreter/virtual
> machine parts and specialized in that specific section, which is good
> because we need manpower.

AFAIC that's the main goal, indeed.

But last I checked Guile didn't have much manpower either.  And there's
a good chance that tracking Guile development (after switching to Guile)
will also require manpower on Emacs's side.  So it's not clear that it
would turn out to be an advantage.


        Stefan