emacs-devel
[Top][All Lists]
Advanced

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

Re: Emacs Lisp's future (was: Guile emacs thread (again))


From: Lally Singh
Subject: Re: Emacs Lisp's future (was: Guile emacs thread (again))
Date: Wed, 17 Sep 2014 15:25:32 -0400


On Wed, Sep 17, 2014 at 2:24 PM, Jorgen Schaefer <address@hidden> wrote:
On Tue, 16 Sep 2014 18:03:17 +0200
Lennart Borgman <address@hidden> wrote:
> Perhaps also the lack of possibility to enhance Emacs with code
> written in other languages? I think for example that _javascript_ will
> be something most future programmers will know. Could Guile make it
> easier to enhance Emacs with _javascript_ (as an alternative to Elisp)?

I think the (often-cited, not just here) idea of supporting multiple
languages is a red herring, mostly. Every extension language supported
adds some burden on those who want to understand what their editor
does, not just use pre-packaged code. One of the great things about
Emacs is that, once I know ELisp, I have a good chance of understanding
and modifying any extension I see. And learning Emacs Lisp is not
exactly hard.

I think a policy of "if written for emacs, do it in elisp" is a good one, but let's acknowledge the advantage of easy linking/calling into other code bases that may come with having a multi-language-compatible runtime system.  I'm sure we've all seen some systems that we'd love to invoke directly from elisp.
 
[snipping some very good points] 
One thing I think would benefit Emacs Lisp as a language a lot would be
a standard library cleanup. An effort to go through the libraries that
come with Emacs, separate them into "standard library" and "extensions
that come with Emacs", and then go through the "standard library",
provide sane names when necessary (like setcar is provided for rplaca)
and deprecating the old ones, or simply deprecate all but one version of
functions with overlapping use (nth or elt, pick one). Finally, add
standard libraries for common functionality that is currently lacking
(see above).

I completely agree that there's plenty of work needed there, but:
 - If staying with elisp, this is a separate discussion
 - If not staying with elisp, these problems can be addressed during conversion.


reply via email to

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