On Wed, Sep 17, 2014 at 2:24 PM, Jorgen Schaefer wrote: > On Tue, 16 Sep 2014 18:03:17 +0200 > Lennart Borgman 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.