Re: About Emacs Modernisation Project

[Evans Winner]

pjb@informatimago.com (Pascal J. Bourguignon) writes:

    I mostly agree with you, (and I'm letting me being
    convinced that emacs lisp itself has some value for
    casual "programmers"), nonetheless it occured to be
    rather often that I had problems in my code because of
    collision of dynamic variable or function names.

There is a great quote from Richard Stallman which you have
probably read:

    Multics Emacs proved to be a great success --
    programming new editing commands was so convenient that
    even the secretaries in [Greenberg's] office started
    learning how to use it.  They used a manual someone had
    written which showed how to extend Emacs, but didn't say
    it was a programming.  So the secretaries, who believed
    they couldn't do programming, weren't scared off.  They
    read the manual, discovered they could do useful things
    and they learned to program.[1]

To me this attribute seems to be the sine qua non of
extension languages.  If it isn't easy enough that people
who either don't program for a living, or who do, but not in
Lisp can pick up enough to be useful relatively quickly,
then the language is not going to take off the way Emacs
Lisp has.

    Common Lisp has compilers that produce code as efficient
    as C, so that indeed the whole emacs could be rewritten
    in CL instead of C+elisp.  And this would allow the
    practical use of other user languages (such as
    JavaScript or Python) to program emacs, since they can
    be, and are implemented more efficiently in CL than in
    emacs lisp.
 
Yes, that makes sense.  Playing Devil's Advocate for a
moment, though, I know Guile scheme is meant to run
JavaScript and Emacs Lisp and, I think, TCL.  But how much
code really runs on it, and how much is written for it?  And
if someone wrote a major package of TCL code to run on
Guile, how much support would it get from the Guile
developers or community?  I find myself thinking that the
result is more likely just a dissipation of resources.  Is
it really better to have an Emacs that nominally supports
ejacs and clpython and Common Lisp and TCL and Scheme and so
on, but really is only serious about Common Lisp -- or an
Emacs that really seriously supports one language: Emacs
Lisp, which is powerful, mature, easy to write and read, and
does what it is supposed to: text editing?

I sympathize with the desire to have a better, stronger,
lispier operating environment; perhaps a better answer is
the approach that I think the Climacs developers have taken:
not to put the mail reader and the chat client and so on
into the text editor, but to put the editor in the Lisp, and
let people write separate mail readers and such.  With free,
multi-threading, cross-platform Common Lisp environments
this seems quite possible now.  But if the goal is a large
user base and all the advantages which that can give, then I
still think that there will be a problem unless that
environment provides something on the level of simplicity
that Emacs Lisp provides; and in the case of Common Lisp, I
don't think that will happen without a major cultural shift
among CL hackers.  Anyway, that's my sense of it.


Footnotes:

[1] Stallman, Richard.  "My Lisp Experiences and the
Development of GNU Emacs."
http://www.gnu.org/gnu/rms-lisp.html