Re: [boost] A bike shed (any colour will do) on greener grass...

Subject: Re: [boost] A bike shed (any colour will do) on greener grass...
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2013-10-31 17:00:09

On 31 Oct 2013 at 13:27, Nevin Liber wrote:

> > It would require some political bravery from the SC though, as users
> > will get upset.
> 
> First you'd have to get the SC to agree with you.  It would be weird for an
> organization that provides a fairly stable base of libraries to users to
> arbitrarily go mess with that stability.  IMHO, of course.

Oh sure. Arguments like these of mine are done with the expectation 
few will agree with me, and with near zero chance of changing 
outcomes. You'll see the same when I make these sorts of arguments to 
WG21 study groups where usually I am told just how many ways I am 
wrong. It's still worth doing, or I wouldn't get such detailed and 
lengthy negative responses.

> Why is usage within Boost itself any more important that usage by users? 

Boost needs to eat its own dog food, including dealing with 
consequences of its own internal self management policies. Boost 
users do not - they are free to hack Boost into any bespoke 
configuration which suits them.

I'll clarify this more specifically: Boost may choose to act as a 
shining light of how to do C++, and as a result may enact a 
deprecation and C++ feature upgrade strategy which would be 
considered aggressive by most standards. Users are affected by this, 
sure, but they can and do keep custom Boost distros (e.g. including 
non peer reviewed libraries) which track HEAD without necessarily 
doing so verbatim. In other words, they don't have to buy in to the 
degree Boost must buy into itself.

Beman and others have mentioned a vision of a Boost v2.x. I got the 
sense such a v2.x edition would be leaner than the present edition. 
The deprecation strategy I proposed is one of many ways of deciding 
what ought to get cut, and it does come with the huge advantage of 
fairness.

> I don't see how the issue is any different; if you remove a library, you
> break somebody.  Why is it "good" to break outside users but "bad" to
> break internal users?  To me, both are bad. 

Change always implies breakage by definition. Even if the breakage is 
in buggy behaviour becoming broken (i.e. fixed). Not breaking 
*always* equals stagnation.

I've noticed that most software engineers prefer to design software 
to be easily added to more than easily removed from. That strategy 
works long term if and only if transistor and storage densities keep 
rising exponentially.

I've often spoke privately with various people (e.g. at C++ Now) 
about what will come to our industry when that gravy train runs out 
and hardware capacity growth goes linear. I think the biggest change 
to our practice will be implementing steady state software - software 
which neither grows nor shrinks in footprint, but evolves, and I 
expect a ton of present large multinationals to go bankrupt as they 
fail to adjust quickly enough. The good news is that I think some of 
the very best and most interesting software will be made once 
hardware advances stop subsidising us, and I in particular have 
detailed hopes for what to do when that watershed comes.

Anyway, getting off topic, but my point is that there appears to be a 
general feeling that Boost has become too big. Many feel 
modularisation will fix this. I personally have severe doubts on 
that, but I guess we'll all see how it pans out and we'll go from 
there.

Niall

-- 
Currently unemployed and looking for work.
Work Portfolio: http://careers.stackoverflow.com/nialldouglas/