Re: Why is Elisp slow?

[Ergus]

Hi Stefan:

I mostly agree with you and I get your points but I have some comments about.

On May 4, 2019 4:03:28 PM GMT+02:00, Stefan Monnier <monnier@IRO.UMontreal.CA> 
wrote:
>> 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?
>
I totally agree with the complexity of mixing languages; but if we look around 
it is very difficult to attract new users and developers if they need to learn 
a new (old fashion) language only for Emacs (as I have been doing the last 
months). New programmers generations only know python and some C-like languages 
but specially OOP and maybe is the moment to think a bit in the future of the 
project more than in the past. Even if that implies taking some risks and make 
hard desitions. Just give a look how popular are sublime text or athom, that 
compared to Emacs those are kid toys.

So at some point it will be needed to make this desitions because the old 
developers will not live forever. I see the beauty of Lisp, but I am talking 
more about a human issue here, that is more critical for Emacs right now and 
for the future.

>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.
>
IF we could do so (embed the CL compiler as a submodule within emacs) and this 
can improve performance (while reduce the amount of code we need to maintain, 
and the number of field experts we need to reach and attract ourself) I'll 
totally support such desition. It is not THE solution we need but it will 
reduce some of the important issues. And will make the project development more 
dynamic and sutainable. But if we can't take such desition right now is because 
we have few people to do the work and the new potential users/developers live 
in a different world with python java rust lua C++ Ruby but also saturated of 
cheaper (easier to use and that do work without learning curve) alternatives 
like notepad++, visual studio code, geany, eclipse, kdevelop... and so on. And 
some of them have put a lot of effort in improving the editing capabilities, 
programming functionalities and ergonomy more than implementing a pdf reader or 
games withing the tool. So they only do one thing but they do it right (or good 
enough for the user general needs) without initial configurations.

For the developers it is also easier to join to those projects because they are 
hosted on Github/gitlab with a more familiar workflow and interface, no 
copyright procedure, no mailing list.... and everything in the same please and 
integrate with a fork based workflow. You can see where I'm going right?

I don't say that all this is better or worst than what we have, it is just what 
the new generations understand, learn in the universities. Otherwise we are 
developing Emacs for us and the already existing users only. Ignoring where is 
the programming world now and where it is going.


>> 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)

Vicious circle no-projects-interested means no users with issues which means no 
potential developers. Any way I was talking about guile because it was the 
official gnu language for extensions similar somehow to elisp and with a full 
platform more or less ready to use without license issues.

>will also require manpower on Emacs's side.  So it's not clear that it
>would turn out to be an advantage.
>
>
>        Stefan

-- 
Enviado desde mi dispositivo Android con K-9 Mail. Por favor, disculpa mi 
brevedad.