Re: [libvirt] [PATCH] docs: document that C & Python are the preferred languages

On Thu, Sep 05, 2019 at 12:30:27PM -0400, Laine Stump wrote: > On 9/5/19 10:51 AM, Andrea Bolognani wrote: > > On Thu, 2019-09-05 at 15:42 +0100, Daniel P. Berrangé wrote: > > > On Thu, Sep 05, 2019 at 04:22:17PM +0200, Andrea Bolognani wrote: > > > > On Thu, 2019-09-05 at 12:42 +0100, Daniel P. Berrangé wrote: > > > > > + The libvirt repository makes use of a large number of programming > > > > > + languages. There is a general desire to phase out some of the > > > > > + existing languages used to reduce the knowledge burden on > > > > > + developers, and facilitate introduction of new languages in > > > > > + the future. > > > > > > > > Reducing the number of languages used by the project and facilitating > > > > the introduction of more languages seem to be contrasting goals. > > > > Accordingly, I would leave out the last part of the sentence. > > > > > > That are actually directly related. The aim is to eliminate some > > > existing languages, so that when we add more languages, we've not > > > increased the overall burden. > > > > I think the fact that we want to add more languages only makes > > reducing the number of languages more pressing than it would be > > otherwise, but reducing the cognitive load for contributors is a > > worthy goal in its own right and alone would be enough to justify > > standardizing on Python in my opinion. So I'd still prefer it if > > you dropped that last part of the sentence, but I won't insist > > further if you're adamant that you want to keep it. > > Maybe part of the reason he's saying that is so that the statement can't be > used in the future as an argument against adding a new language? Generally speaking it *should* be used as an argument against adding new languages. Given current state of the world I'd only make exceptions for Go or Rust, because they are the only credible options for replacing use of C as an efficient systems programming language. I get what you're saying though. > How would you feel about something like: > > "reduce the knowledge burden for old/lame languages on developers and > make room in their brains for a more painless introduction of new/cool > languages into the codebase in the future." Lemme think about it some more. Mostly what I was struggling with was trying not to promise a bunch of ponies that we've not yet delivered on. The HACKING file should really reflect what current committed best practice is. THings would be much clearer if I could set out a general "vision" or "roadmap" for language usage, where I could talk about where we want to get to in 5 years hence, despite it not being the case today.