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

[Andrea Bolognani]

On Thu, 2019-09-05 at 18:14 +0100, Daniel P. Berrangé wrote:
> 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.

How about we add a paragraph at the end of the section that says
something along the lines of

  Both the lists above are subject to change: code written in a new
  programming language might be accepted if it's generally agreed
  that the advantages of using that specific language instead of one
  of the preferred ones outweight the resulting increase in cognitive
  load, and that might in turn result in one of more of the preferred
  languages losing their status; in the same way, languages that have
  been purged from the project in the past might once again become
  acceptable, although such a reversal would require an even more
  impressive cost/benefit ratio.

?

-- 
Andrea Bolognani / Red Hat / Virtualization