Re: Why is Elisp slow?

[조성빈]

Looks like the point of getting Guile Emacs recurs to:

* How much Guile Emacs is polished(seamless integration with Elisp, full 
compatibility, etc..)
* How much Guile supports other languages such as JS or Lua
* How much Guile manages to be fast

Guile Emacs was developed for at least 15 years or more, right?

How much can Guile Emacs do these in current situation?̊̈
Is Guile Emacs usable day-to-day?


> 2019. 5. 3. 오후 9:51, Ergus <spacibba@aol.com> 작성:
> 
> On Fri, May 03, 2019 at 08:52:06PM +0900, 조성빈 wrote:
> 
>> The difference between Guile and CL is that
>> * Guile is arguably not popular and not used by many programs. I've never 
>> heard a program that is popular and uses Guile as an extension language. CL 
>> is, well, much more popular than Guile, and is used by industry-strength 
>> programs.
> 
>> * Guile (which is a scheme) has a radically different syntax with
>> elisp (which means that to implement elisp in Guile, one has to hack
>> the byte code interpreter AFAIK). Elisp can be implemented inside CL
>> with full compatibility, which mitigates lots of problems between
>> interfacing between CL code and elisp code.
> 
> But Guile is in fact developed in the gnu project, so there are the
> Guile developers (very few but they are) that could potentially
> provide and fix any issue. But also the strong part of Guile is not the
> language itself but the potential of the infrastructure.
> 
>> * I'm pretty sure CL will be much, much faster than Guile.
> 
> Probably, that depends of the compiler not only the language.
> 
>> CL was optimized for about 30 years or so, and SBCL compiles CL all the way 
>> to native code, which is comparable to C. I'm not sure if Guile can do that.
> 
> Guile has been also optimized (in spite of there is a lot of work to do,
> that's true) and yes, it can generate native code, but also
> bytecode. But it also offers a lot of functionalities to extend and work
> as a glue language which is actually most important in our days.
> 
> At the end (in my opinion) if emacs wants to survive other 40 years it
> will need to start looking for integration with python, lua, C++, rust,
> Ruby and similar languages with a more "promising" future than common
> lisp. Because we really need to attract new developers with new ideas,
> visions and experiences... and 99% of programmers don't use any lisp
> like language.
> 
> To make big changes we need more developers, that will not come if we
> don't have more users first. And those new users/developers can enforce
> the new changes looking at the future and not to backward compatibility.
> 
> 
>>> https://www.gnu.org/gnu/rms-lisp.en.html 
>>> <https://www.gnu.org/gnu/rms-lisp.en.html>
>> 
>> I read the link; it's a pity to not consider CL because it isn't "lispy" 
>> enough.
>> 
>>> 
>>>> IMHO building emacs on CL would be a wonderful idea... and would fix many 
>>>> problems that current Emacs have.
>>>> 
>>> And create others, it is always a trade off.
>> 
>> What problems would CL based Emacs can make? Can you show some examples? I 
>> am genuinely interested.
>> 
> 
> Dynamic scoping rules vs exical scoping rules in common lisp is just the
> first one I can remember, but maybe someone else will reply you with more 
> details.
> 
>>> 
>>> Any way
>>> 
>>> I have to say that comparing to other interpreters around the Elisp is
>>> not the slowest one I have tried by far. Of course it could be way
>>> faster, but some optimization like user code and provide new containers
>>> and datatypes in the library level based in C (and recomend them) code
>>> could potentially make more difference in real user extensions.
>> 
>> Well, CL is as fast as C.
> 
> But again, common lisp is just a language. Performance is more associated
> with the compiler you use. Cython makes python very fast too for
> example AND IT IS PYTHON!!!.  The latest version of the GNU common lisp
> compiler (GCL) was in 2014... so its developement goes slower than
> Guile.
> 
> If we had a native compiler for Elisp it could be as fast as common lisp
> (ideally). But in any case it needs to be something that goes embedded
> within emacs (otherwise emacs won't be emacs anymore).
> 
> Think also in the licenses issues and legal consequences of such strong
> dependency for a key part of the editor.
> 
> On the other hand it is true that in that case that will be a part of
> the code that we won't need to maintain if we rely on other packages.
> 
> Let me say something. I am not opposed at all to switch to common lisp,
> (or scheme or python, actually I think that at some point it will be
> needed to change the core language for something more flexible)
> what I mean is that this specific problem is not a language issue, but the
> compiler. And I don't think that we can just copy the SBCL code into
> emacs for many reasons.