Re: [boost] The future and present of Boost

Subject: Re: [boost] The future and present of Boost
From: Christopher Kormanyos (e_float_at_[hidden])
Date: 2018-10-21 20:16:37

 > 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 <boost_at_[hidden]> wrote:  
 
 On Sun, Oct 21, 2018, 18:51 Robert Ramey via Boost <boost_at_[hidden]>
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