Re: Preview: portable dumper

[Eli Zaretskii]

> From: Richard Stallman <address@hidden>
> CC: address@hidden, address@hidden
> Date: Tue, 29 Nov 2016 11:55:16 -0500
> 
> Maintaining the portable dumper will be far simpler than maintaining
> unexec.  Unexec has to write a file in whatever format the system uses
> for executables.  If that is ELF format, it is very complicated,
> and it wasn't designed for this purpose.  It is necessary to copy
> the material from the temacs executable, and modify it along the way.
> 
> All those problems will be absent for the portable dumper, which
> will make its maintenance much easier.

Easier: yes.  Easy enough: no, not IMO.  Not for most of the Emacs
contributors we have and will have in the near future.

The number of people aboard who can matter-of-factly hack the Emacs
internals on the C level is consistently going down, and is already so
small they can be counted on one hand.  We must make Emacs depend less
on people from this small and diminishing group, if we want the
development pace increased or even kept at its current level.  To me,
that means keep as many features out of low-level C, and limit futzing
with C-level internals of Lisp objects and the Lisp interpreter to the
absolute minimum.  IOW, any feature that can have an alternative
implementation in Lisp should not be done in C, even if the Lisp
implementation will be slightly slower.

>                     On top of that, adding Lisp objects will now require
>   > writing its dumper back-end, so this will be a constant maintenance
>   > burden of the kind that only a few of us can bear.
> 
> Yes, but how often do we make such changes?  Once every few years,
> I think.

More like once a year, maybe more.

> And it won't be a big difficulty to do so, if the code of the dumper
> is clean.

For you and me, and for a few others, sure.  But Emacs cannot be
developed by a handful of people anymore.  We already fall behind with
frequency of releases, with the speed of delivering new features, with
analyzing and fixing bugs reported to the tracker, etc.  If we don't
attract more core developers, we will never get out of this vicious
cycle.  And bringing C-level core developers on board is a very slow,
painful, and unreliable process, because C programmers are a dying
breed, and Emacs internals are not for the faint at heart.

> I am sure it will be a lot cleaner than the code of unexec.

I'm sure, too, but that's not the issue.

>   > Making the initial load of preloaded Lisp files (most probably, a
>   > single large file) fast enough to allow us to dump the dumping phase
>   > altogether is a much more perspective direction.
> 
> I think this has its own difficulty -- the need to represent everything
> in Lisp syntax.

I don't think I follow: what we preload in loadup already has Lisp
syntax.