Re: Preview: portable dumper

[Daniel Colascione]

On Sat, Dec 03 2016, Eli Zaretskii wrote:
>> From: Daniel Colascione <address@hidden>
>> Cc: Karl Fogel <address@hidden>,  address@hidden
>> Date: Fri, 02 Dec 2016 14:28:25 -0800
>> 
>> We've all been contributing to Emacs for many years. I think we have a
>> pretty good grasp of the issues and potential problems.  I understand
>> that you think there's an existential risk that goes into this change,
>> but I think you're mistaken, and a lot of other people agree. We all
>> have access to the same information; it's unlikely (but not impossible)
>> that you're the only one who can see certain potential problems.
>
> Assessment of trends and their impact on the future, with all the
> uncertainties involved, requires more than just processing the
> immediately available information.

What information then?

We are both rational creatures.  If we disagree, it's either because one
of us made a leap of logic that other has not or because we're starting
with different postulates. Can we please get at the root of
our disagreement?

What evidence would convince you that you were incorrect? On my part, I
might be swayed by examples of other free software projects that have
failed due to the inclusion of C code. I cannot think of any.

It is very frustrating to be asked to believe radical assertions made
without any evidence; that's what happened on the thread-safe malloc
thread, and it was very unproductive.

>> Please give this change the benefit of the doubt.
>
> I thought I was already doing that.  Isn't that why the code will be
> on a branch soon?

The branch will be short-lived. I will want to merge this code
soon. It's at that time that I will most appreciate being given the
benefit of the doubt.

>> Even if your worst-case scenario comes to pass, the worst outcome
>> outcome will just be more fiddly maintenance.
>
> We already have such "fiddly maintenance" situation in several areas.
> Font selection, font back-ends, character composition, complex script
> shaping, and (to some extent) the interaction with X and its window
> managers -- all of these are areas where bugs are left for months and
> years without being fixed, and no progress is made to adapt Emacs to
> the new technologies out there.

The reason that these bugs aren't getting fixed is that they're not
bothering people enough to provoke fixes. I know that I'm much more
inclined to fix bugs when they bother me personally. It's misleading to
cite unfixed minor bugs as evidence that nobody knows how to fix the
bugs.

Placing restrictions on the people who do know how to fix these bugs is
a good way to ensure that we'll either leave them unfixed (thinking it
not worth the trouble to justify the addition of C code) or just keep
the fixes local (which I confess to doing, for this reason).

You know why I haven't worked on the GTK+-only backend I proposed? I
don't *need* to yet. The X11 one works fine, with fixes here and
there. One day, it won't work fine anymore, and either I or someone else
will make it work fine. This situation is not evidence that we're
forgetting how to program GUIs. It means that we did an adequate job.

As for "adapting Emacs to the new technologies out there": that is
precisely what the portable dumper does! I sent a patch that adapts
Emacs to modern technologies and you're complaining that nobody is doing
that. What do you expect me to think?

> IOW, "the worst outcome" is already here.  I'm desperately trying not
> to make it worse.

Emacs runs fine and has many users. It's influential in the community. I
have no idea how many users we have, but I find Emacs users in every
group of developers I visit. emacs-devel is a high traffic mailing
list. We make the news on every major release. If this situation is "the
worst outcome", the worst outcome is pretty comfortable.

Bugs in the sections of code you mention get fixed when you allow them
to get fixed --- Stefan had to try very hard recently to get the
before-change-functions bug fixed, and that was a simple fix for an
egregious problem.

>> I think the pdumper code is pretty clean; I'm open to suggestions
>> for making it moreso.
>
> I will definitely try to keep this in mind when reviewing the code.
> However, code cleanness is not the main problem, based on the above
> examples.  There's nothing unclean in the code in any of the areas I
> mentioned.  The problems are elsewhere.

Yes. I don't think anyone is concerned about code quality. There is
literally nothing I know how to do to this code to make you feel better
about merging it. I feel like the code's very existence is what bothers
you, and I can do nothing about that except give up, which I won't
do. If my assessment is incorrect, and there is something I can do to
the code to make you feel better about it, please let me know.

>> If there's no one left who can understand pdumper, there's no one
>> left who can understand the GC either.
>
> GC is stable for many years, and "just works".  Bugs only happen there
> when people make changes in GC code, for benefits that are not
> essential.  If there's no one on board who understands GC, we can
> simply disallow any changes in that area.

The surest way to ensure that nobody understands a piece of code in a
free software project is to put up a big sign that says "OFF LIMITS! DO
NOT TOUCH!". People learn by doing. You need to let people experiment.
Moving fast (and breaking things occasionally) beats OWNERS. Emacs is
not pacemaker firmware. It's not flying an airplane. A bug introduced is
not the end of the world. We can bisect. You can't simultaneously lament
that the flow of new core developers is a trickle and keep the spigot
turned off.

Your position on this matter has never made any sense to me.

> By contrast, the portable dumper is new code.  No matter how simple
> and clean, it will take some time until it becomes mature enough to
> raise to the current status of GC.  Until that happens, we cannot
> afford being in the same situation as with GC.

Half the people on emacs-devel understand the GC. The other half could
understand it with a few days of study. The last time we had a major GC
bug (the purespace symbol reference thing), we quickly had two
independent patches for fixing it.  (Mine lost, but that's history.)
Both of those path authors are on this thread. This outcome doesn't
suggest that GC is in danger of becoming abandonware. If pdumper ends up
in the same position GC is in today, that's fine.

Speaking of future-proofing Emacs: I'd appreciate fixing the
conservative GC problem I highlighted a few days ago before it becomes a
real bug. Maybe I misread the messages, but my sense was that you were
firmly against that change as well, and I never figured out why.

>> You won't have to touch this code.
>
> I most probably will, and I have no reason to be afraid of that.  But
> this isn't about me.

You are the only one objecting. Perhaps, generally speaking, your
opinion carries greater weight, but it should not carry infinite
weight. Please defer to the judgment of the rest of the community. This
change is not an existential threat. We are not the enemy.