Re: Flood of commits from July?

[Gavin Smith]

On Sun, Oct 06, 2024 at 07:24:13PM +0200, Patrice Dumas wrote:
> On Sat, Oct 05, 2024 at 06:37:45PM +0100, Gavin Smith wrote:
> > 
> > And that is precisely what I DON'T want to happen.  I am not willing to
> > work on texi2any any more if parts of it start being written in C++.
> 
> While I agree that there is no point in rewritting in C++ the existing C
> code, I see no problem with accepting a converter written in C++ that
> would integrate well with the Perl and C converter codes and provide
> with the needed interfaces.  That would require someone willing to write
> it and maintain it.

If it's accepted as part of the Texinfo code base it is the responsibility
of the Texinfo developers to maintain it, fix reported bugs, keep it
working with other changes in the code etc., at least if we want to still
be able to release the code in a working state for general use.

In the hypothetical situation somebody wrote an entire converter written
in C++, it's hard to imagine that one person could take responsibility
for maintaining the C++ code while other developers are able to ignore
it while they work on other areas of the program.  In practice changes
would affect many different parts of the program and developers would
end up having to look at both C and C++ parts while trying to work out
problems with the code.  I never agreed to maintain C++ code so if it
gets to that point this part of the Texinfo code will languish with less
developer attention.  (That's already the case with some other parts
like info.js with infog (the WebKitGTK-based HTML documentation reader)
which I have hardly had time to work on.)

> > It is possible that texi2any could be rewritten in a different language
> > in the future but I don't know what that language is.  The language might
> > not even have been invented yet.
> 
> In any case, having already C code written as it is now would hopefully
> help people wanting to do something related to Texinfo in high level
> languages and speed up some parts of the processing with low level
> functions.

Yes I understand the benefit of having both high-level and low-level
languages combined.  Python was mentioned in another message in thread
and although this is a nicer language than Perl (from my perspective, as
someone who has never programmed in Python), I am led to believe that
it is even slower than Perl.  I was thinking in the future there may
be some other language that is both high-level (e.g., automatic
memory management) and fast enough.