Re: [boost] Thoughts on Boost v2

Subject: Re: [boost] Thoughts on Boost v2
From: Roland Bock (rbock_at_[hidden])
Date: 2014-05-17 06:41:40

On 2014-05-16 19:10, Niall Douglas wrote:
> On 16 May 2014 at 17:46, Stephen Kelly wrote:
>
>> There is clearly not agreement within Boost that anything should be done at 
>> all regarding modularization, before a more 'big bang' break forward, from a 
>> reading of the mail from Niall.
> For the purposes of clarity, I am not a member of Boost. I do not sit 
> on any committees, and have no representation nor standing with the 
> community apart from doing some admin for GSoC. I would say that my 
> opinions on this are so extreme that no one agrees with me, and I 
> expect my presentation at C++ Now tomorrow to not be popular.
If /really/ you think that, why do you do that presentation?

This is one of the most intense threads for long. Some thoughts of yours
are provocative, sure, but hey, that might lead to a lively discussion
at the conference (I'd love to be there).

Anyway, have good luck in finding the right words and stirring a discussion!

>
> I have however been doing a lot of canvassing whilst here at C++ Now. 
> The main problems with Boost which are causing its decline are these:
>
> 1. Boost isn't sexy any more. As one very highly respected world 
> famous engineer put it - and I won't say who, and I apologise to him 
> for stealing his words without attribution:
>
> "Boost used to be about all the stuff you really wanted in the 
> standard. Now Boost looks like all the stuff that wasn't good enough 
> to get into the standard"
I disagree. The libraries which made it into the standard are the ones
which were most in demand like range based for, smart pointers, thread
and regex. And sure, there are some libraries which will probably never
make it into the standard, and sure, not all are of the same quality,
but there are quite a few extraordinary ones, too!

Metrics for code and documentation quality as well as responsiveness of
the author would certainly help to filter out the sub-par ones over time.
>
>
> 2. Everyone recognises there are serious problems with process, 
> everything from how you were treated Stephen when you tried cleaning 
> out cruft and only really Dave supported you, right through to the 
> fact that peer review simply doesn't work any more. The Boost 
> community has become quite selfish in recent years, as you would 
Selfish? That's the wrong word, I'd say. But there are quite a few
people involved. It takes some time to make them move into a new direction.
> expect from those with a vested interest in the status quo before 
> evolution. And for the record, I have no problem with those vested 
> interests keeping their existing Boost, but I personally want as far 
> away from C++ 03 as soon as is possible.
Throwing support for C++03 overboard is a huge change in direction. I
would really love to see that change, but it will take some time.

And there is movement in that direction. Louis Dionne is working hard on
mpl11, Eric Niebler has ported (or is porting?) proto to C++11. These
are important steps towards a C++11 version of boost 2.0.

>
>
> 3. All the interesting new C++ 11 libraries you find around the 
> internet have zero interest in trying to join Boost, with a very few 
> honorable exceptions. That speaks volumes, to me at least.
There were always many more C++ libraries outside of boost than inside.

>
>
> Which suggests to me a need for a new Boost which attempts to apply 
> the benefits of hindsight to what we learned with Boost v1. Now, it 
> is extremely clear from this conference there is little appetite for 
> that, but I think later on this year we're going to have three C++11 
> libraries in the queue, and if things have not very significantly 
> progressed in any of the three items above, I think that time will be 
> right time to fork. And here is what I think should be in a fork of 
> Boost:
>
> 1. Minimum required compiler feature set will be VS2014's. No use of 
> Boost STL permitted where the C++ 11 STL provides a feature.
Personally I would say C++14 with Concepts Lite should be the platform
to use. Starting with C++11 is going to be outdated in the near future,
I guess.
Otherwise: +1
>
> 2. cmake instead of Boost.Build.
+1
>
> 3. Eliminate peer review in favour of a suite of automated libclang 
> based AST analysers. Instead of persuading people to review 
> libraries, persuade them to review and improve the AST analysers.
That sounds pretty weird. How could such an analysis say if (for
instance) Boost.Spirit is well written and worthy of Boost??
>
> 4. Mandatory cross platform per-commit CI with unit testing exceeding 
> 95% coverage. We don't care what unit test library is used so long as 
> it can output results Jenkins can understand.
+1
>
> 5. Mandatory all green thread, memory, UB sanitisers and clean 
> valgrind. All also tested per-commit.
?
>
> 6. Mandatory CI testing for exception safety. I am hoping a clang 
> rewriter can basically patch all exception throws and have them 
> randomly throw for testing.
Nice idea!
> 9. There is no longer an "in" or an "out" for distribution. I'm 
> thinking of a scorecard page where member libraries are ranked by how 
> high quality they are according to all the automated review, so when 
> I say "mandatory" above, I simply mean they don't get to appear on 
> the main downloads page without that precondition. All submitted 
> libraries do appear though, just ranked very low if their quality is 
> low. I would hope all this is generated from a database and requires 
> very little human input.
+1 for the general idea
>
> 10. BoostBook documentation using the Boost look and feel becomes 
> mandatory. I've had enough with library authors thinking they can 
> improve on BoostBook's output with things like using Comic Sans as 
> the font or weird colour schemes throughout.
+1
> Thoughts?
Keep on stirring. Personally, I believe that you will receive more
support for that idea than you seem to expect.

Cheers,

Roland