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

["brian m. carlson" <sandals@crustytoothpaste.net>]

[-- Attachment #1: Type: text/plain, Size: 2950 bytes --]

On 2021-04-17 at 21:37:57, Ævar Arnfjörð Bjarmason wrote:
> 
> On Sat, Apr 17 2021, brian m. carlson wrote:
> > 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.
> 
> "This change" as in the patch or my informal summary of what I think the
> current status quo is?

The patch.

> The change being proposed here isn't to say that you can never write a
> new thing in shell, but advice that actively encourages that for
> prototyping.

I think in many cases it is valuable to use it for prototyping still.

> > 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.
> 
> ... but since we're sharing our own opinions :)
> 
> As someone with >100 commits in perl.git, I don't think I can be thought
> to be uncomfortable with the language.

I am duly aware of this fact, having worked on a mainly Perl codebase
full-time for 6 years.

> So it sucks for the individual author, but at this point the trade-off
> of whipping something new up in e.g. *.sh isn't just that the thing
> doesn't need to be performant, but e.g. in the case of the gettext
> integration means we'll be stuck with the fixed costs of extending
> certain core APIs to shell-land forever, whereas currently it's looking
> like we might be able to "git rm" much/most of that stuff sooner than
> later.

I think it's worth keeping the shell script stuff around because I think
it adds a lot less friction to building new tooling.  I'll be frank: I'm
not massively in love with C, despite having known it since I was 10,
nor is our C particularly elegant (memory leaks, tons of global
variables, etc.).  I think there can be an argument made that in a lot
of cases, shell or Perl is the better option when performance isn't
essential, and so I think those should continue to be first-class
languages in our codebase, even if that means we need to put a little
more effort into maintaining them.

Moreover, we still have a decent number of scripts using the shell
tooling, so I'm not sure they're going away quite as quickly as you'd
hoped.  I agree they're not as numerous as they used to be, but they're
still not entirely gone, nor do I think they're going to all disappear
anytime soon.
-- 
brian m. carlson (he/him or they/them)
Houston, Texas, US

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 263 bytes --]