help-gnu-emacs
[Top][All Lists]
Advanced

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

Re: About Emacs Modernisation Project


From: Evans Winner
Subject: Re: About Emacs Modernisation Project
Date: Wed, 08 Dec 2010 15:11:04 -0000
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux)

Stefan Monnier <monnier@iro.umontreal.ca> writes:

    But [Emacs] has a lot of legacy which is a large part of
    its popularity and longevity.

Emacs isn't just something I put up with because it has a
lot of legacy.  I would argue that it has that legacy
precisely because it was the right tool for the job; that
job is editing text.  It's nice that some people have
managed to engineer large systems to run in the extension
language of a text editor, but I'm not sure it's then fair
to conclude that therefore the editor should be re-written
in some other language that is designed for large complex
systems.

In any case, a distinction must be made (I think) between
Emacs Lisp and core Emacs, written in C.  To me, re-writing
the core of Emacs in Common Lisp sounds like it might be a
great idea, but it's well out of my depth.

    Indeed.  But lexical scoping and name spaces wouldn't
    make any difference in this respect.

Perhaps not.  What I can say is that if Emacs Lisp were
Common Lisp, I would never have gotten serious about using
Emacs.  I know that I am not alone in this.  Emacs is a text
editor used by many people, and not all of them are CL
hackers -- not all of them are even programmers.  Some are
just writers -- text editors are good for writing text,
actually, not just code.  I would bet that there are a great
many writers and other non-programmers out there who in fact
do write useful Emacs Lisp code because Emacs Lisp is the
kind of language that they can understand well enough to use
to write useful code.  It is certainly not correct to
characterize non-professional programmers as needing or
wanting only to setq a few variables.  The dichotomy is not
that clear, and Emacs Lisp was, as I understand it, designed
precisely in recognition that computer users are
programmers, fundamentally, and deserve the power of a real
programming language, but editing text does not require the
complex overhead of an industrial-strength language.

Granted, one can always program in a simple subset of Common
Lisp if one wants to, or as Pascal mentioned, write a DSL --
and the real issue is a cultural one.  I can look at
reasonably straight-forward Emacs Lisp and often tell what
is going on and where to make changes if I need to; the same
is not true of Common Lisp.  Part of the reason is cultural
-- the coding standards for Emacs, the liberal use of doc
strings, for instance, have "trickled down" to a great deal
of third-party code written for Emacs.  The Common Lisp
culture doesn't appear to me to have caught that wave.  So
perhaps it would not be so bad.  But if the Common Lisp
culture is an example, the result of an Emacs written in
Common Lisp would not be lots of libraries that users could
look at and easily modify, but a small amount of
tightly-written, totally inscrutable code that only a
die-hard CL hacker could love -- or even understand.  I know
it would be technically possible to make an Emacs in Common
Lisp that was as useful to non-experts as current Emacs is,
but I don't believe that it would actually happen -- that it
is culturally likely.  CL Emacs would become a specialty toy
that only a few would know enough about to use productively.

As for Emacs in Python et al, the same, only more so.

I say all this not because I am an expert, obviously, but
precisely the opposite.  I think that it is not such a given
that Emacs ought to be re-written in Scheme or CL, and those
who want to do it may find that it's a hard sell to get some
Luddites like me using it, that's all.


reply via email to

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