Re: Emacs rewrite in a maintainable language

[Eli Zaretskii <eliz@gnu.org>]

> Date: Tue, 13 Oct 2015 10:27:16 +0200
> From: Przemysław Wojnowski <esperanto@cumego.com>
> Cc: emacs-devel@gnu.org
> 
>     I don't think this is possible.  Some slowdown will be inevitable.
> 
> IMHO the performance is overestimated.

I don't think it is (see below).  But in any case, I was simply
responding to a wish, which you deleted, that said:

> Or a more radical approach: a Lispy language, easy to learn by those who
> already know Elisp, but which can be translated all the way to something
> as performant as the current C code
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

My observation above simply says that "Lisp translated into C" will
always be somewhat slower than hand-written C.  That's all.

> Look at Java based IDEs - Idea, Eclipse, Netbeans, etc.
> All of them have been written in _slow_ Java (at least according
> to C standard) and run on _slow_ JVM. But all of them are able to
> attract more users that Emacs, which has core in blazing fast C.

Err... isn't "IDE" the subject of another thread?

In this thread, we are not talking about attracting more users, we are
talking about attracting more _developers_ for the core C code.

Anyway, we do have in Emacs a few known performance critical spots,
and if we switch to another language, we would like to avoid making
them slower in transition.

> The truth is that nobody cares about performance as long as it is
> _good enough_.

Sure.  And under some circumstances Emacs does show performance
problems precisely by that criterion.  For example, the display engine
is sometimes (fortunately, rarely) too slow to degrees that annoy
users.  Rewrite those parts in a slightly slower language, and you
have a larger problem; in particular, the rare situations where this
shows might become less rare.  We don't want that.

> IMHO C lacks basic abstractions that reduce conceptual weight of
> any subsystem/library/concept/etc. Interfaces and namespaces do.
> Static typing would also help.

As Daniel already wrote in this thread: don't underestimate the
complexity of Emacs that has nothing to do with the implementation
language.  Emacs solves quite a few very complex problems; the
solution is therefore complex, and will be so no matter in what
language you express it.  That complexity is IME the main obstacle for
newcomers to Emacs maintenance.  The rest is non-negligible, of
course, but good engineering practice is to solve the main problem
first, and go for the secondary one only afterwards.

Therefore, I think efforts to improve the documentation, commentary,
and readability of the code will yield higher gains faster than
switching to another language.