What If Python Replaced Elisp?

[Matt Curtin]

>>>>> "Tad" == taashlo  <taashlo at sandia.gov> writes:

  Tad> This morning I was making some changes to my .emacs file and I
  Tad> thought how much easier it would be to use Python instead of
  Tad> Elisp for this purpose.

Would it be easier for you because you're more comfortable with Python
than with XEmacs Lisp?

  Tad> Now I realize that rewriting XEmacs (my favorite emacsen) to
  Tad> use Python rather than Elisp would be an enormous undertaking
  Tad> that would (probably?) not payoff.

Emacs folks, I believe especially XEmacs folks, have discussed this
several times.  The most common idea of this type seems to be
replacing the XEmacs Lisp engine with Perl, or adding Perl as a second
engine for extension.  The less radical discussions of this type have
been moving from ELisp to GUILE (for GNU Emacs) and whether to move to
GUILE or Common Lisp as the extension language for XEmacs.

Look for "Perl", "Common Lisp", and "GUILE" in news:comp.emacs.xemacs
archives and in xemacs mailing lists, which are archived at
http://www.xemacs.org/.  That should provide some useful and
interesting food for thought on the topic.

  Tad> I saw a comparison of Lisp and Python at
  Tad> <http://www.norvig.com/python-lisp.html> which stated that Lisp
  Tad> can be about 100 times faster than Python.  I'm going to assume
  Tad> that this doesn't hold true for Elisp.

Obviously, how much of a difference there will be will depend largely
on the specific task at hand.  However, I think it's probably safe to
say that byte-compiled XEmacs Lisp is much faster than Python on
average.  It would be interesting to do some tests to see just what
kind of difference there is.

  Tad> (Beginner WAG: Python 'feels' just as fast, if not faster, than
  Tad> Elisp.  But some of the packages (e.g. font-lock) rely heavily
  Tad> on regular expression parsing, which may be slower in Python.)

Keep in mind that your comparisons here aren't even close to being
apples-to-apples.  It would be more interesting to see you do
something like rewrite `hanoi' in Python and compare that speed to
what's in XEmacs.  Until you're working with the same program, one
implemented in XEmacs Lisp and the other in Python, you're not going
to have a good feel for which is really faster.

  Tad> Would it be easier to add a COM (automation) interface to
  Tad> XEmacs if Python were used instead of Elisp?

I do not see why.

  Tad> Would the GUI be improved by using Tkinter or wxWindows?

Improved?  I doubt it.  As an example of the GUI's completeness,
XEmacs has hooks for things like CDE drag-n-drop.

  Tad> What other advangages/disadvantages would arise due to this
  Tad> change?

A huge amount of code would need to be implemented in the language of
any new engine.  A lot of things would need to change the way that
they implement various pieces, but most of these would be manageable.
implemented in a way that's depending on a "functional" viewpoint.

I definitely wouldn't like any such change.  I don't see any real
advantages that would be offered by using Perl, Python, or anything
else so radically different from XEmacs Lisp.  My question is "what
does XEmacs Lisp not do for you?"  If it's a question of not knowing
the tool (as it has been in the case of some similar suggestions in
the past), the correct answer is probably to learn the tool better
instead of suggesting a replacement.

-- 
Matt Curtin cmcurtin at interhack.net http://www.interhack.net/people/cmcurtin/