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:
signature.asc
Description: PGP signature
