emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Emacs Lisp's future


From: Phillip Lord
Subject: Re: Emacs Lisp's future
Date: Wed, 17 Sep 2014 14:54:22 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)

Stefan Monnier <address@hidden> writes:

>> I've been going through some 10 year old elisp of mine recently.
>> The thing that surprises me is how many times I mention performance in
>> it.  I rarely worry about this these days.  Elisp performance as is
>> seems rarely an issue.
>
> I think this reflects 2 things:
> - machines still did get faster over the last 10 years (much less so
>   than over the preceding 10 years, but also probably much more so than
>   over the next 10 years).

Well, Emacs is a text editor. The CPU demands of the task haven't
increased that much over the last 10 years either.

> - you've internalized Elisp performance sufficiently that you
>   self-censor yourself such that you don't bump into it.

Have you looked at any of my code recently? Still, yes, you may have a
point.



>
>> Where I would say that there is an issue is that too much of Emacs is
>> written in C.  Having a faster elisp would allow moving more into lisp
>> and thus having more of Emacs extensible dynamically.
>
> That's part of the idea, yes.
>
>> I'd add a fourth. People who want to extend Emacs for their own purposes
>> have to learn it.  Having JS extensibility would be an enourmous win.
>
> I'm far from convinced.  It may seem that way if you don't think too
> hard about what it would look like, but once you realize that your JS
> hacker will have to learn how to manipulate Elisp lists, Elisp vectors,
> Elisp symbols, how to access Elisp functions and Elisp variables ...
>
> That JS code won't look very much like your typical JS code.  It will be
> so baroque that they will "have to learn it".  And they may even hate it
> more (because it surely will look ugly).
>
> Interoperability between languages is *hard*.  Doing it so the result is
> lightweight and elegant (and moderately efficient) is rarely possible.

Yes, you are absolutely right. I am using Clojure for its Java interop
at the moment, and it has been done well. Replicating that would be no
mean feat.

Phil



reply via email to

[Prev in Thread] Current Thread [Next in Thread]