Re: [PATCH] CodingGuidelines: remove suggestion to write commands in Perl/SH

From: brian m. carlson <sandals@crustytoothpaste.net>
Date: Apr 17, 2021, 20:28 UTC
Message-ID: <YHtFBeWxE2cFlShY@camp.crustytoothpaste.net>
In-Reply-To: <87r1j91427.fsf@evledraar.gmail.com>

On 2021-04-17 at 12:36:00, Ævar Arnfjörð Bjarmason wrote:

Show 21 quoted lines

> 
> On Sat, Apr 17 2021, Bagas Sanjaya wrote:
> 
> > On 17/04/21 15.43, Ævar Arnfjörð Bjarmason wrote:
> >> Since then the consensus changed to having no new such commands unless
> >> necessary, and existing ones have been actively migrated to C.
> >
> > What I implied that when we need to implement new commands, it must
> > be directly written in C (steeper learning curve and more tedious
> > than implemented in shell script), so I'm against this proposal.
> 
> I updated the v2 of this to note that I'm not really proposing anything
> new, but just bringing the document in line with reality. For a long
> time now we've rejected any new non-C things being imported into the
> tree, unless those that fall under the "such as an importer to convert
> random-scm-X" language that's still retained in the CodingGuidelines.
> 
> I think that even if you or someone else wanted to write a new thing in
> Perl or SH we'd want a new way of doing that now anyway,
> e.g. git-send-email.perl should really be a helper for a C program
> rather than a stand-alone thing.

I'm also kind of opposed to this change. For example, I plan on adding a utility to fill in SHA-1 compatibility things for SHA-256 repos, and that will be written in shell. The performance benefit of C here is going to be minimal, especially considering the fact that people will be running it literally at most once per repo, so I don't see a reason to spend a lot of time writing C code.

I'm not of the opinion that we should never have shell or Perl code in our project, nor does it intrinsically make sense to migrate everything to C. Typically we've done that because it performs better, especially on Windows, but there are many situations in which those are not major considerations and shell or Perl can be a desirable approach.

-- 
brian m. carlson (he/him or they/them)
Houston, Texas, US