Re: Why is Elisp slow?

[Ergus]

On Mon, May 06, 2019 at 09:08:03AM -0400, Stefan Monnier wrote:
> > That's what vim did and they now support many languages for extending
> > and create plugins. (I know it is a different system and I am not saying
> > we have to move in that direction right now.)
>
> Yes, it's a very different design.  Elisp was designed to be the
> *implementation* language of Emacs (the use of C for some of the
> implementation was a necessary evil given the lack of wide availability
> of Lisp), rather than just an *extension* language.
>
>
>        Stefan
Yes, but then we need to put much more emphasis (and work) improving and
keep good performance in the compiler (which is a much more complex task
than maintaining the editor, and where very few changes are made these
days). Apply the new tools and techniques in compiler sciences and so on
requires a very high level of expertise. OR consider migrate to
something else that someone else maintain like SBCL or whatever the
managers consider better. (I know that only this proposal will open a
sacred war (as it did before (but the problems are the same)) but being
sincere is more valuable than being politically correct to have
progress)

Because many editors around can already do what emacs do (edit text, be
extensible, free, and portable), but they have faster interpreter and
language, better (more familiar or standardized) keybindings, bigger
communities, simpler (in spite of more limited or not) customization and
simpler code or "more pretty/intuitive" UI.

Lisp was the right option 40 years ago because it was probably the most
dynamic language and easier to understand than C for the computer users
that time. But now there are more dynamic and capable languages. And a
language interpreter is not so easy to maintain for a formal/big project
like emacs.

Summing up. In Spanish we say that whoever takes a lot of space, the
less he tightens up (bad translation: Quien mucho abarca poco aprieta).

IN MY OPINION, we should put more attention in the emacs editing
capabilities/functionalities/interface and rely the compiling
functionalities to a compiler we can (with limitations of course)
trust. Even if that means remove the E letter from our language. But
after that big change any compiler released in future will be easier to
use as a module and we could even give the option to the user to
chose.

(I know this sounds a bit heretic) but being a bit more DOTADIW will be
more scalable and maintainable now and in the future. And we can center
the manpower in update the gui, optimizations, cleanup
old/unused/unmaintained code, solve bugreports, standardize keybindings
and so on.