Boost logo

Boost :

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

> 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


Currently unemployed and looking for work.
Work Portfolio:

Boost list run by bdawes at, gregod at, cpdaniel at, john at