Re: [boost] The future and present of Boost

Subject: Re: [boost] The future and present of Boost
From: Robert Ramey (ramey_at_[hidden])
Date: 2018-10-22 14:56:50

On 10/22/18 1:49 AM, Niall Douglas via Boost wrote:
>> All one has to do to see this is look at the papers list for the San
>> Diego meeting.  Also look at P0977r0.  Consider that it take the
>> committee 10 years for a proposal to evolve into something that can be
>> delivered to users. It even takes 10 years to include something which is
>> already in use by 100's of thousands of programmers - ASIO.
> 
> In fairness, this is because its champions refuse to split ASIO into the
> bit everybody agrees with - the synchronous API - from the bit which is
> dependent on stuff not finished i.e. the asynchronous API.

> If its champions were willing to fold deadlines/timeouts into the
> synchronous API and leave off the asynchronous API for C++ 23, they
> could ship, now, for C++ 20. So in the end the lack of any Networking in
> C++ 20 is 100% down to its sponsors and champions, not the committee who
> have repeated pleaded - even formally by Direction itself (P0939) - to
> get Networking into C++ 20.

This is what I'm talking about.  Design by the standards committee is 
not a good use of the committees time and resources. If they insist on 
mandating libraries (itself a bad idea), the should just stick to 
evaluation of existing libraries.

>> Of course the C++ committee won't address the situation.  Committees
>> don't do that. They think they can remain relevant by expanding scope.
>> and lo and behold, now they want to expand scope again to include
>> tooling.  Wake up and smell the coffee people.  Learn to prioritize and
>> limit the scope of your actions to that which only you can do.  This
>> would be better for C++.  Do less - get more done!
> 
> You may not yet be aware that WG21 is launching lots of new SGs, and
> spitting LEWG into pre-LEWG and LEWG all as part of handling better the
> increased workload. Its scope has markedly increased from even a few
> weeks ago.

LOL - Right.  This is what all organizations do when they are faced with 
the failure to accomplish their stated objectives.  They add more 
objectives!  The try to become too big to fail.  Sears heads down the 
toilet and they ... buy Lands End.  It's an all two familiar patter. 
What they need to do is cut scope back to something they can actually do 
a good job on.

> And now to Antony ... On 21/10/2018 19:33, Antony Polukhin via Boost wrote:
> 
>> Ranges is a very popular library. It is still an "existing practice", but
>> that practice is not from Boost.
>>
>> Here's a crazy idea - include into Boost all the prototypes that were
>> accepted into C++. This will keep the Boost important and usefull. Users
>> will be able to find all the upcomming libraries in one place.
> 
> Eric Niebler is on record saying the primary reason he didn't submit
> Ranges v3 to Boost was the documentation requirement, which was onerous.

So he couldn't meet the requirements of Boost so it went to the 
standard. Boost standards exceed those imposed by the committee!  This 
is why Boost is more successful than the committee in promoting 
development of quality libraries.

> My main blocker for finishing Outcome is having to rewrite the
> documentation yet again. Everything else was finished six months ago.

I've had a lot to say about documentation.  My advice to you and others 
with this complaint is that you must be doing it wrong.  If you're 
waiting until the end of the process to add documentation, you're 
missing out on getting a better design.  Here is what I have to say on 
the subject: https://www.youtube.com/watch?v=YxmdCxX9dMk  Just follow 
these instructions and you'll find documentation a joy to write and the 
quality of your libraries will be much improved.  You'll also find the 
review process, be it at C++ committee or at Boost, much, much less 
onerous - almost a pleasure. And you'll find that the review itself will 
be much, much more helpful than you've found in the past.

> If Boost could start leveraging its ample cash reserves to solve the
> documentation problem, that would solve the problem.

Hmmm - I'm not seeing how spending more money would change peoples way 
of going about it.  It's not a technical problem.

> So, specifically
> speaking, each year the Boost SC allocates a fixed chunk of cash for
> documenting some reference library implementation of an approved
> upcoming C++ standard library. A popularity vote is held by Boost on
> which of the choices should win this. The winner has professional
> technical writers hired to write the documentation. The finished result
> appears on boost-dev for a mini-review. If approved, it enters Boost.

It would be free and alot easier if people just spent a little time 
learning how to do it properly.

>> Another idea: how about dropping the "review manager" requirement? Allow
>> library author to manage the review and require a separate manager only if
>> the votes for library inclusion are doubtful or there's less than N votes.
> 
> I'd strongly oppose this, except where a review manager can be
> substituted by WG21 having formally decided to standardise a library.

Hmm - once a library is standardized, I believe that vendors are 
required to provide it so that their compiler is considered 
"conforming".  BTW - how a compile with easily demonstrable bugs are now 
considered "conforming" is beyond me.

> I appreciate lack of review managers gates the number of new libraries
> in Boost [1].
> 
> But, to be blunt, Boost is about *popular* libraries. If a library can't
> find a review manager, not enough enough of an itch is there to be
> scratched. That's the whole point of having review managers, to filter
> out too-niche libraries.

Personally, I've got no problem with "too niche" libraries.  You're 
right they might have to scrounge around for a review manager.  But as 
you note this is not a big problem.

> [1] I really, really, really, really wish Boost would expunge the
> undermaintained libraries already. They waste productivity for so many
> people out there who think they're using a Boost quality library, when
> they're not, and get badly burned for it.

If Boost were able to support modular deployment, this problem would go 
away.  That is, if a library weren't being used, no one would download 
it and it wouldn't matter.

Robert Ramey