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/