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-23 14:44:17

On 10/23/18 2:11 AM, degski via Boost wrote:
> On Tue, 23 Oct 2018 at 10:44, Niall Douglas via Boost <boost_at_[hidden]>
> wrote:
> 
>> Interestingly, P1031 Low level file i/o and the Networking TS are not
>> examples of those. Both require changes to the core language to work
>> well. So I think for those two at least, they'd be before the committee
>> no matter what.
>>
> 
> But maybe [some of those] TS's should be permanent fixtures, sort of like
> associated libraries (SAL) [with added support in the language where
> required, to accommodate those]. The 2D Graphics should be in there as
> well. Writing client/server applications and/or 2D games are not things
> everybody does, they should not be standard libraries. But there are more
> of course, f.e., a GUI lib and a Crypto lib.

I'm not sure what this says - but it might be on the right track.

If doing a good job for something like network TS requires some changes 
in the core language, then maybe the committee should focus on just 
those "enabling" changes.  This would permit the development of network 
libraries untethered by the standard. So the network TS would be more of 
a use case, example, case study or whatever.

The same could be said for 2d graphics.  Perhaps some core facilities 
need to be added. Example might be standardizing a low level interface 
to SIMD graphics processors.  If so, these would be suitable scope for a 
C++ committee.  At the same time, there are lot's of different visions 
for a 2d graphics package.  Trying to sort through this and arrive at a 
consensus will just end up displeasing everyone.

And the above arguments apply to other stuff.

But this begs the question: C++ needs a robust and complete set of high 
quality libraries to continue to prosper - and where are these going to 
come from?  My argument is that organizations such as Boost are the 
prime candidates to fulfill this role.  But in order to do so, things 
have to evolve.  Boost is fine as far as it goes.  But thinking about 
the future we need to address some things:

a) as Nail as mentioned - an effective deployment strategy for C++ 
components.  Given the nature of C++, binary API, tons of build options, 
lack of standard definition for things like visibility, runtime loaded 
code, etc.  This is a very, very, very difficult problem in design and 
implementation.  It's not going to be resolved by some committee with 
100 people on it.  Maybe, some genius will come of the woodwork and 100 
people can agree - this is a big improvement.  That's what I'm aiming 
for with "Call for Submissions - CMake for Boost".  yeah, it's a crap 
shoot - albeit one with little downside.

b) Part of this has to be finding ways to improve component reliability, 
ease of use, transparency/verifiability, and other measures of quality. 
For some reason, most programmers don't see any problem here. Personally 
I don't understand why - maybe it's just me.

c) The above two are really about making components "composable".  This 
a key strength/feature of C++.

c) Drawing more people into the "monastic order" that is Boost.  Boost 
is too hard to be a part of (though as far as I know there is no current 
celibacy requirement, but a CoC could change that).  A lot of this can 
be addressed by addressing the above points.

I see a huge vacuum crying to be filled and Boost is in an ideal 
position to fill it.

Robert Ramey

> 
> degski
>