Re: Why is Elisp slow?

[Ergus <spacibba@aol.com>]

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.