Re: Emacs rewrite in a maintainable language

[John Wiegley]

>>>>> Óscar Fuentes <address@hidden> writes:

> In large part because that reason, there are key are parts of the C core
> that are only understood by one active hacker (being optimistic here). This
> is a huge liability for Emacs. I don't know how this fact fits the "C is
> working for us" stance.

Of all the languages I know, I can't think of one that gives us everything we
need: stability, performance, portability, a large potential contributor base
(people who know C can learn the macro system Emacs uses), debugging tools,
etc.

The C core needs experts, not so much in C, but at writing display engines and
algorithms important to Emacs. I find it hard to believe that the "Lisp in C"
macros we use on the C side to allow seamless integration are the stumbling
point for those who want to contribute. Am I wrong in this? Has this turned
people away from working on Emacs core?

C works for us because it does what it says on the tin. Emacs runs on a huge
number of systems, is efficient, and the project continues to thrive after
many decades.

I'm against changing "because the grass is greener". Give it a decade or so,
and I'd happily join in rewriting the core in Haskell. But when I think about
the difficulty of running on alternative systems (the dependencies alone might
kill us), or non-expert contributors introducing space leaks that only
manifest for specialized use cases... I'll take C any day. C diffs are clear
and concise as to their actual semantic content. This is also a reason Linus
has given for keeping the Linux kernel in C.

I'm not saying I love C. I spent a career working in C, then finally fled for
greener pastures. But show me an alternative that comes even remotely close,
and I'll happily consider it.

John