|
From: | Lally Singh |
Subject: | Re: Emacs Lisp's future (was: Guile emacs thread (again)) |
Date: | Wed, 17 Sep 2014 15:25:32 -0400 |
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.
[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).
[Prev in Thread] | Current Thread | [Next in Thread] |