[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
- Re: Emacs Lisp's future, (continued)
Re: Emacs Lisp's future, Lars Magne Ingebrigtsen, 2014/09/17
Re: Emacs Lisp's future, Phillip Lord, 2014/09/17
- Re: Emacs Lisp's future, Nic Ferrier, 2014/09/17
- Re: Emacs Lisp's future, Stefan Monnier, 2014/09/17
- Re: Emacs Lisp's future,
Phillip Lord <=
- Re: Emacs Lisp's future, Eli Zaretskii, 2014/09/17
- Re: Emacs Lisp's future, David Kastrup, 2014/09/17
- Re: Emacs Lisp's future, Eli Zaretskii, 2014/09/17
Re: Emacs Lisp's future, Phillip Lord, 2014/09/17
performance isn't a concern in ... Emacs Lisp's future, Nic Ferrier, 2014/09/17
Re: performance isn't a concern in ... Emacs Lisp's future, David Kastrup, 2014/09/17
Re: Emacs Lisp's future, Thorsten Jolitz, 2014/09/18
Re: Emacs Lisp's future, Stefan Monnier, 2014/09/17
Re: Emacs Lisp's future, Taylan Ulrich Bayirli/Kammer, 2014/09/17
Re: Emacs Lisp's future, David Kastrup, 2014/09/17