The future and present of Boost

classic Classic list List threaded Threaded
71 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

The future and present of Boost

Boost - Dev mailing list
This was on another thread. Someone mentioned that it should be on it's
own thread so here it is (slightly amended for context).


For some time I've been concerned about the future of Boost as an
organization.  Here are the concerns I have:

a) With C++11, the standards committee accepted a large portion of Boost
into the standard.  This left it unclear as to what the future value of
Boost to C++ might be.

b) The standards committee has ramped up it's efforts to include library
proposals directly into the standard - thus side stepping the
traditional requirement of "standardizing established practice".  So
this has left Boost, which helps to evolve "establish practice" outside
of the development of the C++.  An example of this has been the Ranges
library which as been designed and developed totally within confines of
the C++ standards committee.  This effectively marginalizes Boost - that
is, makes it less relevant and important.

c) This effort by the committee is basically failing.  It's creating the
possibility that C++ will evolve into an ever larger and
incomprehensible bag of disjoint features than it already is. It makes
it much harder to learn C++. This puts C++ on a slow train to oblivion.
This is not unusual with successful projects which expand their scope -
as the committee has done.  It's especially common for organizations run
as a committee.  Think large corporations: Kodak, Sears, All government
organizations, universities - etc.

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.

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!

d) Boost can accept, review and deliver a new library in a year. Hence
Boost has a reason to continue and exist. But Boost is also a committee
- albeit a better designed one. It has to evolve as well. I think it can
evolve if we continue to work on the stuff we've been successful at
while at the same time experimenting with new ideas.

Robert Ramey


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: The future and present of Boost

Boost - Dev mailing list
On Sun, Oct 21, 2018, 18:51 Robert Ramey via Boost <[hidden email]>
wrote:
<...>

> b) The standards committee has ramped up it's efforts to include library
> proposals directly into the standard - thus side stepping the
> traditional requirement of "standardizing established practice".  So
> this has left Boost, which helps to evolve "establish practice" outside
> of the development of the C++.  An example of this has been the Ranges
> library which as been designed and developed totally within confines of
> the C++ standards committee.  This effectively marginalizes Boost - that
> is, makes it less relevant and important.
>

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.


c) This effort by the committee is basically failing.  It's creating the
> possibility that C++ will evolve into an ever larger and
> incomprehensible bag of disjoint features than it already is. It makes
> it much harder to learn C++. This puts C++ on a slow train to oblivion.
> This is not unusual with successful projects which expand their scope -
> as the committee has done.  It's especially common for organizations run
> as a committee.  Think large corporations: Kodak, Sears, All government
> organizations, universities - etc.
>

I always tell people - do not put efforts into complaining, put efforts
into fixing things. If you see that features do not interact well - write a
paper and propose a fix.


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.
>

Let's be honest. 10 years of evolution made Networking TS better. Take a
look at all the changes with const_buffer_1, allocators ... It's worth it.


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!
>

Committee  become bigger. More people could process more papers and deal
with bigger scopes.


d) Boost can accept, review and deliver a new library in a year. Hence
> Boost has a reason to continue and exist. But Boost is also a committee
> - albeit a better designed one. It has to evolve as well. I think it can
> evolve if we continue to work on the stuff we've been successful at
> while at the same time experimenting with new ideas.
>

+1.

I'm really interested in having all the C++2x prototypes in Boost. Looks
like everyone would benefit from that. Is that a reasonable idea?

>

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: The future and present of Boost

Boost - Dev mailing list
 > For some time I've been concerned about the future of Boost as an
> organization.  Here are the concerns I have:

<A lot of concerns>...

Thank you for sharing your concerns. Perhaps others havesimilar concerns. Maybe there is a lack of syhcnronization inthe symbiosis between Boost and C++. Well, one thingto do might be to talk about it. What are the common directionson each side? Where are things going? Is there a written agendaor a set of goals for the future? Or are the two areas simply beginningto operate asynchronously?

To this day, C++ is for me personally a very powerful andexpressive languagethat can be used all the way from tinyembedded systems up to supercomputers. This kind of flexibility
and portability has benefitted from the close contact betweenBoost and C++.

C++ can also produce work of very high quality that adheresto standards in a measurable fashion via code metrics,safety rules, etc. This is uniquely positive and can not besaid of some other languages.
I guess the best thing to do might be to figure out how andwhere C++ and Boost fit together and what both sides areconsidering for the future.
With kind regards, Chris
    On Sunday, October 21, 2018, 8:35:22 PM GMT+2, Antony Polukhin via Boost <[hidden email]> wrote:  
 
 On Sun, Oct 21, 2018, 18:51 Robert Ramey via Boost <[hidden email]>
wrote:
<...>

> b) The standards committee has ramped up it's efforts to include library
> proposals directly into the standard - thus side stepping the
> traditional requirement of "standardizing established practice".  So
> this has left Boost, which helps to evolve "establish practice" outside
> of the development of the C++.  An example of this has been the Ranges
> library which as been designed and developed totally within confines of
> the C++ standards committee.  This effectively marginalizes Boost - that
> is, makes it less relevant and important.
>

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.


c) This effort by the committee is basically failing.  It's creating the
> possibility that C++ will evolve into an ever larger and
> incomprehensible bag of disjoint features than it already is. It makes
> it much harder to learn C++. This puts C++ on a slow train to oblivion.
> This is not unusual with successful projects which expand their scope -
> as the committee has done.  It's especially common for organizations run
> as a committee.  Think large corporations: Kodak, Sears, All government
> organizations, universities - etc.
>

I always tell people - do not put efforts into complaining, put efforts
into fixing things. If you see that features do not interact well - write a
paper and propose a fix.


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.
>

Let's be honest. 10 years of evolution made Networking TS better. Take a
look at all the changes with const_buffer_1, allocators ... It's worth it.


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!
>

Committee  become bigger. More people could process more papers and deal
with bigger scopes.


d) Boost can accept, review and deliver a new library in a year. Hence
> Boost has a reason to continue and exist. But Boost is also a committee
> - albeit a better designed one. It has to evolve as well. I think it can
> evolve if we continue to work on the stuff we've been successful at
> while at the same time experimenting with new ideas.
>

+1.

I'm really interested in having all the C++2x prototypes in Boost. Looks
like everyone would benefit from that. Is that a reasonable idea?

>

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
 

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: The future and present of Boost

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 10/21/18 2:33 PM, Antony Polukhin via Boost wrote:

> On Sun, Oct 21, 2018, 18:51 Robert Ramey via Boost <[hidden email]>
> wrote:
> <...>
>
>> Boost has a reason to continue and exist. But Boost is also a committee
>> - albeit a better designed one. It has to evolve as well. I think it can
>> evolve if we continue to work on the stuff we've been successful at
>> while at the same time experimenting with new ideas.
>>
> +1.
>
> I'm really interested in having all the C++2x prototypes in Boost. Looks
> like everyone would benefit from that. Is that a reasonable idea?

Boost now consists of >150 libraries, a number of them barely
maintained. Who do you propose would maintain those additional projects ?

I think before we can even think of an endeavour of that scale, we
should fix the scalability issues we already have.


Stefan

--

      ...ich hab' noch einen Koffer in Berlin...
   


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: The future and present of Boost

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 10/21/18 11:33 AM, Antony Polukhin via Boost wrote:

> On Sun, Oct 21, 2018, 18:51 Robert Ramey via Boost <[hidden email]>
> wrote:
> <...>
>
>> b) The standards committee has ramped up it's efforts to include library
>> proposals directly into the standard - thus side stepping the
>> traditional requirement of "standardizing established practice".  So
>> this has left Boost, which helps to evolve "establish practice" outside
>> of the development of the C++.  An example of this has been the Ranges
>> library which as been designed and developed totally within confines of
>> the C++ standards committee.  This effectively marginalizes Boost - that
>> is, makes it less relevant and important.
>>
>
> Ranges is a very popular library. It is still an "existing practice", but
> that practice is not from Boost.

Hmmm - where is it?  I'm aware of Boost Ranges but not of any other
library which implements a similar facility.

> 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.

Right, I'm sure that boost would be willing to review any such libraries
when they are submitted.

Robert Ramey


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: The future and present of Boost

Boost - Dev mailing list
On Sun, 21 Oct 2018 at 22:09, Robert Ramey via Boost <[hidden email]>
wrote:

>
> Hmmm - where is it?  I'm aware of Boost Ranges but not of any other
> library which implements a similar facility.
>
> Eric Niebler's range-v3 library, https://github.com/ericniebler/range-v3
I'm not intimately
familiar with it, but I believe it's all Boost::Range V2 and then some.

Regards

Rob.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: The future and present of Boost

Boost - Dev mailing list
On 10/21/18 3:54 PM, Robert Jones via Boost wrote:

> On Sun, 21 Oct 2018 at 22:09, Robert Ramey via Boost <[hidden email]>
> wrote:
>
>>
>> Hmmm - where is it?  I'm aware of Boost Ranges but not of any other
>> library which implements a similar facility.
>>
>> Eric Niebler's range-v3 library, https://github.com/ericniebler/range-v3
> I'm not intimately
> familiar with it, but I believe it's all Boost::Range V2 and then some.

Actually this is exactly what I was referring to with my point b) above.
Eric is a highly respected Boost Developer (Boost.Xpressive,
Boost.quickbook, and otherstuff etc.)  After C++11 he got an opportunity
to develop ranges under the auspices of the C++ standard committee.
Many of us were disappointed that he didn't choose to do it under Boost.
  But of course it's his choice.

But now Ranges may come as part of the standard in C++20. And then
sometime after may be available when/if compiler vendors choose to
implement their own version.  All in all, the committed would have been
able to spend time on other stuff which only they can do.  And Boost
would have had an modern ranges library years ago.  Also Boost might
have had a useful library based concepts system.  Only now do we have a
modern replacement for mpl - this would have happened years earlier.

Compared to Boost, the C++ committee is an inferior organization to
design and produce quality software.  It's not that they don't have
smart people, it's that the C++ committee structure is setup to define
and approve standards - which is not the same as designing software.

Robert Ramey

>
> Regards
>
> Rob.
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: The future and present of Boost

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Sun, Oct 21, 2018, 23:23 Stefan Seefeld <[hidden email]> wrote:

> On 10/21/18 2:33 PM, Antony Polukhin via Boost wrote:
>
> On Sun, Oct 21, 2018, 18:51 Robert Ramey via Boost <[hidden email]> <[hidden email]>
> wrote:
> <...>
>
>
> Boost has a reason to continue and exist. But Boost is also a committee
> - albeit a better designed one. It has to evolve as well. I think it can
> evolve if we continue to work on the stuff we've been successful at
> while at the same time experimenting with new ideas.
>
>
> +1.
>
> I'm really interested in having all the C++2x prototypes in Boost. Looks
> like everyone would benefit from that. Is that a reasonable idea?
>
> Boost now consists of >150 libraries, a number of them barely maintained.
> Who do you propose would maintain those additional projects ?
>
Authors of the prototypes. They already maintain those, all they have to do
is to use boost namespace and license.
Maintainment of antique libraries is a separate topic. I'd rather not mix
those.

>

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: The future and present of Boost

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Mon, Oct 22, 2018, 00:09 Robert Ramey via Boost <[hidden email]>
wrote:

> On 10/21/18 11:33 AM, Antony Polukhin via Boost wrote:
> > On Sun, Oct 21, 2018, 18:51 Robert Ramey via Boost
>
<...>

> Right, I'm sure that boost would be willing to review any such libraries
> when they are submitted.
>

I'm proposing to relax the review requirements for those libraries. Include
them even if the Boost feedback was "need more work". Simplify the review
process.

We should give users and library authors a simple way to meet and interact.
Boost is a perfect platform for establishing existing practice and ensuring
library quality. Let's not loose it because of the exhausting review
process that requires a lot of time and scares of some of the authors. If
the library accepted into C++ or Library Fundamentals - then it was already
reviewed.


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.

>

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: The future and present of Boost

Boost - Dev mailing list
On Mon, 22 Oct 2018 at 10:16, Antony Polukhin via Boost
<[hidden email]> wrote:
>
> 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.

+1

IOW, let's replace Review Manager with Review Arbiter, only called if necessary.

Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: The future and present of Boost

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
> 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.

> 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.


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.

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

If Boost could start leveraging its ample cash reserves to solve the
documentation problem, that would solve the 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.

Speaking personally, I have something like five reference library
implementations before standards now. All lack documentation, and I have
no intent to write any beyond what is there now. I personally wouldn't
mind investing the work to get some or all of those into Boost, BAR
writing the documentation.

I can't speak for Eric or Casey, but I can see that for them the
additional work to enter Boost - bar the documentation - is fairly
insignificant compared to what has already been invested for standards.
They may well be willing.

Ultimately though somebody needs to create consensus to do this here on
boost-dev, ask the Boost SC for the funding, and then run the annual
competition. Boost has the money, there are lots of Boost-quality
standards reference libraries to choose from. Just somebody needs to do
the admin to make it happen.

> 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.

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.

[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.

Niall

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

The future and present of Boost

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
> -----Original Message-----
> From: Boost <[hidden email]> On Behalf Of Robert Ramey via Boost
> Sent: Monday, October 22, 2018 3:33 AM
>
> But now Ranges may come as part of the standard in C++20. And then
> sometime after may be available when/if compiler vendors choose to
> implement their own version.  All in all, the committed would have been
> able to spend time on other stuff which only they can do.  

They would still have had to spend the time on standardizing ranges-v3.
I don't see how ranges-v3 being in boost instead of a stand-alone repo
would have made any difference for standardization, unless you assume
that it would have produced a much superior design.

Also, considering that the "actual" ranges library depends on
concepts, I don't see how that work could have been done as part of a
boost library which is commonly expected to work with a wide variety of
compilers / compiler versions.

> Compared to Boost, the C++ committee is an inferior organization to
> design and produce quality software.

 
Maybe I'm getting this wrong, but I don't see Boost designing or producing
any software. I see some individuals producing and maintaining great
libraries (certainly in part due to feedback from other boost members)
that may or may not get accepted into boost.

The one thing I can say however is that for standardizing libraries,
a production quality, cross-platform implementation (which may or may not be
part of boost) is much more useful than a TS that doesn't get implemented by
half of the toolchains.

Best

Mike



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: The future and present of Boost

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 10/22/18 11:14 AM, Antony Polukhin via Boost wrote:
>
> 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.

Review manager's responsibility is not to merely count the votes. The
person has to be a reasonable expert in the field, who should see pros
and cons of the library, weigh the points raised in the reviews and make
an informed decision (which might be against the votes, in principle).

And, obviously, the library author, despite any intended honesty, will
be biased in making such a decision.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: The future and present of Boost

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 10/22/18 11:53 AM, Mike Dev via Boost wrote:

>> -----Original Message-----
>> From: Boost <[hidden email]> On Behalf Of Robert Ramey via Boost
>> Sent: Monday, October 22, 2018 3:33 AM
>>
>> But now Ranges may come as part of the standard in C++20. And then
>> sometime after may be available when/if compiler vendors choose to
>> implement their own version.  All in all, the committed would have been
>> able to spend time on other stuff which only they can do.
>
> They would still have had to spend the time on standardizing ranges-v3.
> I don't see how ranges-v3 being in boost instead of a stand-alone repo
> would have made any difference for standardization, unless you assume
> that it would have produced a much superior design.

Existing practice is important for standardization. Generally, being
part of a well-known and widely adopted project like Boost offers more
opportunity for adoption to a new library than it being separate.

> Also, considering that the "actual" ranges library depends on
> concepts, I don't see how that work could have been done as part of a
> boost library which is commonly expected to work with a wide variety of
> compilers / compiler versions.

This is not quite true, in general. IIRC, when Hana was accepted, it was
working only on some bleeding edge versions of gcc or clang, which were
not even shipped in any distros at the time. Of course, Boost libraries
strive for portability, but at the same time they are allowed to require
a certain minimum C++ version. This is a per-library balance.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: The future and present of Boost

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 10/22/18 1:53 AM, Mike Dev via Boost wrote:

>> -----Original Message-----
>> From: Boost <[hidden email]> On Behalf Of Robert Ramey via Boost
>> Sent: Monday, October 22, 2018 3:33 AM
>>
>> But now Ranges may come as part of the standard in C++20. And then
>> sometime after may be available when/if compiler vendors choose to
>> implement their own version.  All in all, the committed would have been
>> able to spend time on other stuff which only they can do.
>
> They would still have had to spend the time on standardizing ranges-v3.

My point is that complex libraries such as ranges, networking, etc.
don't belong in the standard at all.  So in my world, the committee
would spend zero time on these things - thus making available time on
those things that only a standards committee can do.

> I don't see how ranges-v3 being in boost instead of a stand-alone repo
> would have made any difference for standardization, unless you assume
> that it would have produced a much superior design.

Hmmm - the question posed really is whether Boost adds any value at all.
  That is, if a boost library is equivalent to any other library on
github, then what's the point of Boost.  This is actually the
fundamental question that Boost has to face today.

> Also, considering that the "actual" ranges library depends on
> concepts,

I'm not sure that it necessarily depends on concepts.  But even if it
does, Eric implemented his own library based version of concepts.  Paul
Fulks was inspired by that to propose such a library for boost which
failed to pass review.

>I don't see how that work could have been done as part of a
> boost library which is commonly expected to work with a wide variety of
> compilers / compiler versions.

I believe that Eric's and Pauls were both portable.

>> Compared to Boost, the C++ committee is an inferior organization to
>> design and produce quality software.
>    
> Maybe I'm getting this wrong, but I don't see Boost designing or producing
> any software. I see some individuals producing and maintaining great
> libraries (certainly in part due to feedback from other boost members)
> that may or may not get accepted into boost.

Right.  The only software actually designed and produced by Boost are
the Boost building and testing tools.  BTW - how's that working out?

> The one thing I can say however is that for standardizing libraries,
> a production quality, cross-platform implementation (which may or may not be
> part of boost) is much more useful than a TS that doesn't get implemented by
> half of the toolchains.

That's it - the need is for high quality software components produced in
a timely manner.  I don't believe the standards committee can accomplish
this goal.

Robert Ramey

>
> Best
>
> Mike
>
>
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: The future and present of Boost

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 10/22/18 4:20 AM, Andrey Semashev via Boost wrote:
> On 10/22/18 11:53 AM, Mike Dev via Boost wrote:

> Existing practice is important for standardization. Generally, being
> part of a well-known and widely adopted project like Boost offers more
> opportunity for adoption to a new library than it being separate.

Also it allows for evolution.  Standardization does not.  People
complain about io streams being too .... But what would be involved in
getting that fixed now?  No one would invest the effort to get a "fixed"
version through the standards committee.

Robert Ramey


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: The future and present of Boost

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 10/22/18 1:14 AM, Antony Polukhin via Boost wrote:

> On Mon, Oct 22, 2018, 00:09 Robert Ramey via Boost <[hidden email]>
> wrote:
>
>> On 10/21/18 11:33 AM, Antony Polukhin via Boost wrote:
>>> On Sun, Oct 21, 2018, 18:51 Robert Ramey via Boost
>>
> <...>
>
>> Right, I'm sure that boost would be willing to review any such libraries
>> when they are submitted.
>>
>
> I'm proposing to relax the review requirements for those libraries. Include
> them even if the Boost feedback was "need more work". Simplify the review
> process.

We already do this.  Some libraries have been "accepted" with conditions
which have entailed a long time - some times years to meet.  The lastest
instance is the safe numerics library.  This was accepted.  But the
review revealed problems which took 18 months to fix (and still not
quite done).

> We should give users and library authors a simple way to meet and interact.
> Boost is a perfect platform for establishing existing practice and ensuring
> library quality.

I think we have this and I think it's the key feature of boost.
Requirements (testing, docs, etc.) a review processes.  No other option
provides this.

> Let's not loose it because of the exhausting review
> process that requires a lot of time and scares of some of the authors. If
> the library accepted into C++ or Library Fundamentals - then it was already
> reviewed.

Maybe the library interface, but certainly not the rest of it: code,
docs, tests, etc.  BTW, what would be the point of implementing a
library accepted into C++ - Won't that be implemented by the vendor anyway?


> 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.

If an author finds boost requirements to onerous, he should just upload
it to github. He doesn't have to follow Boost at all.  He can even get
it reviewed by reddit/cpp/review - https://www.reddit.com/r/cpp_review/ 
. No need for Boost at all if it's to much of a problem.

Personally, I think the requirements to be accepted into boost too loose
and we should raise them to an even higher standard.

Robert Ramey



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: The future and present of Boost

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
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


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: The future and present of Boost

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
> -----Original Message-----
> From: Boost <[hidden email]> On Behalf Of Robert Ramey via Boost
> Sent: Monday, October 22, 2018 4:29 PM
>
> On 10/22/18 4:20 AM, Andrey Semashev via Boost wrote:
> > On 10/22/18 11:53 AM, Mike Dev via Boost wrote:
>
> > Existing practice is important for standardization. Generally, being
> > part of a well-known and widely adopted project like Boost offers more
> > opportunity for adoption to a new library than it being separate.
>
> Also it allows for evolution.  Standardization does not.  People
> complain about io streams being too .... But what would be involved in
> getting that fixed now?  No one would invest the effort to get a "fixed"
> version through the standards committee.

I didn't say having existing practice isn't important. Actually I did quite
the opposite (quoting myself):

> The one thing I can say however is that for standardizing libraries,
> a production quality, cross-platform implementation (which may or may not be
> part of boost) is much more useful than a TS that doesn't get implemented by
> half of the toolchains.

What I do say however is that
1) having such a widely used implementation doesn't necessarily
   reduce the amount of work the committee has to do in order to standardize:
   Just have a look at the things from boost that got merged into the
   standard (or where the committee is currently trying to merge them).
2) in times where everyone can easily publish their library on github on the
   one hand and projects try to actively shed or avoid their dependency on
   boost, having your library distributed as part of boost is certainly not
   the only realistic way to get lots of usage feedback.
   Ranges-v3 in particular became quite well-known and popular in the c++
   community and I believe the main hurdle to its wide adoption was the
   inability of MSVC to compile it - not that it wasn't part of Boost.

Again, I absolutely don't want to deny the value having a library going
through boost prior to standardization. I'm just not convinced, that it
would have helped the standardization process if ranges where developed
as part of boost.

One general problems I see with standardizing existing practice btw:

A new library designed for use in production rarely gets written against
the latest version of the c++ standard. Once it is written it takes quite
some time until it gets adoped widely and even longer until it really
becomes established practice.

So at the time where you start to work on standardization, the library
is designed against a language that is probably 2-4 Standard revisions
older than the one in which it will gets standardized. Depending on how
much the language changed in between, and how much the library has evolved
in the meantime you need to spend at least some effort (and sometimes
considerable effort) to bring the design in line with modern language
principles (Use std::chrono duration instead of ints, using string_view,
  .
Interesting point to think about: If you look at how standardization of
communication protocols work (e.g. USB, Wifi PCI), they don't standardize
established practice at all.


Mike

>
> Robert Ramey
>
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: The future and present of Boost

Boost - Dev mailing list
On 10/22/18 10:13 AM, Mike Dev via Boost wrote:

> What I do say however is that
> 1) having such a widely used implementation doesn't necessarily
>     reduce the amount of work the committee has to do in order to standardize:
>     Just have a look at the things from boost that got merged into the
>     standard (or where the committee is currently trying to merge them).
> 2) in times where everyone can easily publish their library on github on the
>     one hand and projects try to actively shed or avoid their dependency on
>     boost, having your library distributed as part of boost is certainly not
>     the only realistic way to get lots of usage feedback.
>     Ranges-v3 in particular became quite well-known and popular in the c++
>     community and I believe the main hurdle to its wide adoption was the
>     inability of MSVC to compile it - not that it wasn't part of Boost.
>
> Again, I absolutely don't want to deny the value having a library going
> through boost prior to standardization. I'm just not convinced, that it
> would have helped the standardization process if ranges where developed
> as part of boost.
>
> One general problems I see with standardizing existing practice btw:
>
> A new library designed for use in production rarely gets written against
> the latest version of the c++ standard. Once it is written it takes quite
> some time until it gets adoped widely and even longer until it really
> becomes established practice.
>
> So at the time where you start to work on standardization, the library
> is designed against a language that is probably 2-4 Standard revisions
> older than the one in which it will gets standardized. Depending on how
> much the language changed in between, and how much the library has evolved
> in the meantime you need to spend at least some effort (and sometimes
> considerable effort) to bring the design in line with modern language
> principles (Use std::chrono duration instead of ints, using string_view,

I'm arguing that the C++ standardization process is not useful for most
C++ libraries.  The committee can't handle it.  This is pretty much a
demonstrable fact as far as I'm concerned.  (I realize that people will
disagree with this premise).  So this leaves a vacuum which
organizations such a Boost can/should fill.

>    .
> Interesting point to think about: If you look at how standardization of
> communication protocols work (e.g. USB, Wifi PCI), they don't standardize
> established practice at all.

True, but their not standardizing any practice.  They don't approve code
or APIS etc.  The leave that to someone else. They stick to the
legitimate goals of standardization.

I believe that one of the original goals is to "standardize existing
practice" and perhaps they shouldn't do that.  One thing that they do
which no one else can do is specify language syntax and semantics.
Expanding too far beyond this essential function can compromise the
successful accomplishment of that very function.

Robert Ramey

>
>
> Mike
>
>>
>> Robert Ramey
>>
>>
>> _______________________________________________
>> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
1234