Re: Why is Elisp slow?

[조성빈 <pcr910303@icloud.com>]

The more I think about Guile Emacs and the Guile project itself, I start to think that it’s not a problem of manpower, but something more fundamental. Is it feasible (or even possible) to make two different high level languages to interoperate in the engine level?̊̈
For example, will it even make sense to have some Elisp macros in scheme land, or even lua land, python land, JS land?̊̈

Even if Emacs has limited success in these problem by e.g. transpiling JS to elisp or doing macro expansion at runtime by the Elisp engine, I would like a JSish API for emacs when writing packages, not a low level wrapper around Elisp APIs.
Same thing for Python, Lua, Scheme, etc...
Different languages introduce different concepts that just don’t match.
What would I do to use a Python module in JS?̊̈ Unless the language itself is designed to be easily interoperable with elisp by superseding concepts (such as Clojure superseding Java), I’m pretty sure many people won’t be satisfied in any kind of implementation. 

CL is one (and presumably the only) case that (at least looks like) supersedes Elisp in concepts. (Actually it would be something more like Elisp designed like that.) It’s a Lisp-2, it has macros, it uses S-exps, etc, etc. It also has the advantage that we can leverage the state-of-art CL compilers that produce insane speeds from such a dynamic language.

2019. 5. 5. 오전 9:43, 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.
>