Re: [boost] Boost is supposed to serve *the entire C++ community; it isn't Boost's goal to serve Boost's community*

Subject: Re: [boost] Boost is supposed to serve *the entire C++ community; it isn't Boost's goal to serve Boost's community*
From: Robert Ramey (ramey_at_[hidden])
Date: 2016-05-19 11:36:21

On 5/19/16 2:17 AM, Niall Douglas wrote:
> On 17 May 2016 at 19:39, Edward Diener wrote:
>
>>> But I'll freely admit I have given up on trying to make any
>>> substantial changes to Boost. I prototyped as I said I would a
>>> Boost-lite transition layer suitable for a clean Boost fork which I'm
>>> using in all my own code. Nobody was interested.
>>
>> Maybe no one was interested because no one knows what you are talking about.
>
> This I think is inaccurate except maybe for your good self
> personally.
>
> I presented a plan for how to technically transition to a C++ 14 only
> Boost 2.0 at my C++ Now 2015 presentation:
>
> https://goo.gl/VFFXUl
>
> The talk was well attended, and by much of the more senior Boost
> community members.

I happened to attend that talk.  I'm not sure if I understood it all. 
But I can definitely say that I found the proposition unconvincing.

> I got the impression everyone understood well what was being
> proposed. Understanding was not the issue. Agreement with forking
> Boost into a C++ 14 only edition was the issue.

I saw nothing to be gained by this.  I still don't.  Boost as from day 
one had the policy that any library submitted should be compatible with 
the latest C++ standard. Any library author is free to build his library 
with C++14 only.

Given the above, I never understood what you're proposal was (actually 
is, because I still don't understand it).  Was in some sense to 
deprecate libraries which supported older compilers as well as later 
ones?  How would you enforce this?  Was it to remove libraries which 
support older compilers from the official distribution? What would be 
the point of that if they still support the most recent version of C++?
Was it to fork boost and make C++14 only versions of the current 
library?  Why would making a libraries applicability narrower make 
anything better?  And who would that considerable amount of work? The 
library author/maintainer?  How would for him to do this?  As I said the 
proposal was either not well conceived, not well explained or most 
likely both.

Now if you had proposed something like:  I'd like to make and distribute 
my own boost distribution which includes only those libraries which are 
C++14 compatible but not compatible with older compilers - you don't 
need anyone's permission.  Just have at at it.  It's not a huge task - 
at least compared to the other tasks we do.  Basically it's just means 
making specialized version of some python script and start advertising.

Actually I alluded to some of this during my Boost 2.0 proposals in 
2015.  My concern was accommodating was addressing the expected future 
growth of boost. Here are the relevant proposals

a) Resolve issues related to modularization and dependency management. 
Work on this has been on going and making progress but it's slow going 
as it's a much more difficult proplem than meets the eye.

b) Support development of the ability to generate, test and support 
subsets of the Boost distribution.

c) NOW you could easily propose a subset distribution.  Here are some ideas

i) a distribution which would not include any components which are now 
supported by the standard library.  This would work for those shops 
which want to pick a canonical implementation and not have multiple 
versions of the same thing.

ii) The Naill distribution - this would include only those libraries 
which meet the Naill standard for C++14+ purity.  It sounds to me that 
this is what you're proposing.  As more and more library authors became 
convinced of the utility and popularity of restriction their library set 
to those certified as "Naill pure"  and made changes accordingly, this 
distribution would naturally grow over time. It wouldn't take a lot of 
work to maintained.

iii) Boost recommended distributation - the concensus of what we think 
most programmers should be using and excluding those things that 
wouldn't be recommended for new projects.

iv) The whole enchilada - what we are generating and testing now - which 
would not change.

>>> The community
>>> *likes* things just the way they are: serving the Boost community,
>>> and to hell with the entire C++ community.

I don't think that is anyway accurate characterization of the community 
- particularly those who have written, maintained libraries and/or 
infrastructure.  I also don't think there is any evidence to support 
such a characterization.  You seem to believe that the lack of support 
for your proposal supports this characterization.  Well, it's also 
possible that the large majority of those exposed to the proposal just 
considered it a bad idea.

>>
>> Boost consists of about 130 different libraries. I venture to guess that
>> there is not a single library author of those 130 different libraries
>> that wouldn't like to see his library used more by the C++ community.

Right - obviously.

>> But why you think that Boost library authors write only for other Boost
>> library authors rather than for any C++ programmer is something you need
>> to explain in specific terms. Just making that claim does not explain
>> anything.

Agreed.

> The C++ 14 only libraries contributed to date are clearly written
> first for C++ not Boost.

No problem with that - actually, all the libraries have been written for 
C++.

> They are the future we should be proactively
> encouraging into a new clean ground up redesigned fork of Boost, a

This doesn't follow from any premise so far stated.  Such a fork is a 
very, very, very bad idea as I stated above.  It's also unnecessary to 
achieve what I think you're goals are.  (I doubt I share you're goals 
either - but it doesn't matter.  I challange you to implement as I've 
described above and prove me wrong).

> Boost 2.0, instead of corralling them into legacy and outdated
> packaging, build, design, documentation and idioms out of some
> misguided desire for serving the legacy Boost usership before that of
> the wider C++ community.

I don't see this as a coherent view.  But it doesn't matter.  I believe 
that the path we're on can lead to the ability to create custom 
distributions with different focuses.  I don't see any conflict.  The 
problem is that creating this "modular boost distribution system" is 
much much harder than most people realize.  The number of people who are 
willing to suggest how to change something far, far exceeds the number 
of people willing and able to actually make this happen.

Robert Ramey