Re: implementation language [was: library for unicode collation in C for texi2any?]

[Gavin Smith]

On Thu, Oct 12, 2023 at 01:24:07PM -0700, Per Bothner wrote:
> On 10/12/23 11:35, Gavin Smith wrote:
> > Calling [using Perl] a "mistake" is a very strong statement!  Why do you 
> > say that?
> > Surely texi2any 7.0.3 (2023) is more functional than makeinfo 4.13 (2008) 
> > was.
> 
> That is not a meaningful comparison. The question is: If we had re-written
> makeinfo/texi2any using C++ rather than Perl there is all reason to
> believe it would have been similarly functional at this point.

You can't know that.

> The most obvious reason Perl was the wrong choice was performance: As you
> recently mentioned some people are still using the old pre-Perl tools
> for that reason. And this is after years of tuning the Perl code.

Yes, I agree.

However, many people, if asked at the time, would have said that interpreted
languages were fast enough and many might have said that Perl was a natural
fit for text processing.

The moral is that people can say all kinds of things about programming
languages and it isn't really worth much.

The chances that a project is going to be rewritten because some outsider
comes along and recommends their favourite programming language are nil.
People (me) are not going to put the effort into writing new code in a
language they don't particularly like and aren't very familiar with purely
based on a recommendation.

> Another problem with Perl is that was a relatively obscure language,
> in that not many people had much experience writing big complicated
> programs using Perl. And that has gotten worse in the intervening years.
> A related issue is tooling: There is a lot of available and up-to-date
> tooling for C++, including gdb.
> 
> > I'm not much of a fan of C++ tbh.
> 
> I have a lot of C++ experience, and I am a big fan. For almost any program
> where C might be a reasonable choice, C++ is likely to be a better choice.
> C++ is admittedly a big complicated language - but if you focus on
> C and add classes, methods, and inheritance it's not very complicated
> and it's already a big win over C. Memmory management (RAII) is also easier
> and less error-prone:
> https://learn.microsoft.com/en-us/cpp/cpp/object-lifetime-and-resource-management-modern-cpp?view=msvc-170
> 
> It is much easier to make a large C++ program well-structured and 
> maintainable:
> Classes help immeasurably, as do namespaces.

Could we not get those benefits by writing in Go instead?  (Not that I'm
proposing this).

I have a small amount of experience in C++ with the Qt library
(see https://github.com/GavinSmith0123/OpenBoard/commits/smart-import) and
downsides I have found include long compilation times, long error messages
in the case of templates, and more verbose backtraces with class names.
Adding a function to a class forces recompilation of a large part of the
program due to header files changing.

I have found the "edit - compile - test" cycle much quicker in C and it
is normally quick to find and fix problems in C code using gdb and/or
valgrind.

I suspect that large programs in C++ can have rigid structures that are
hard to change.  It can be hard to change the class inheritance hierarchy
without wide-ranging changes throughout a code base.  (For example,
in the program I was working on, there was one class (an embedded web
browser, I seem to remember) that was an extra parent class for many other
classes (with multiple inheritance), which I believed was unnecessary,
but excising this class proved impossible for me with the time and effort
I put into it.)  New people working on the code, who aren't the original
developers, may also not really understand the structure of the code and
what all the different classes are for and find it hard to restructure
the code.

I expect that C++ may be a good language for large complicated programs
worked on by larger teams where machine efficiency is very important.

Editing C++ code is harder with a standard text editor and you are
pushed to use IDEs to do things like updating header files and getting
autocompletion.

I agree RAII is definitely a win although I doubt that there is such a
thing as a "simple" subset of C++.  You list class inheritance as part of
this although it is only occasionally useful, as far as I understand.  It's
not necessary to have the possibility for polymorphism for every single
function call or operator that occurs in a program.  With C you can easily
trace the flow of execution of a program and see where things go next.