Re: [boost] [outcome] non-interface-related concerns

Subject: Re: [boost] [outcome] non-interface-related concerns
From: Robert Ramey (ramey_at_[hidden])
Date: 2017-05-28 14:54:03

On 5/28/17 4:29 AM, Niall Douglas via Boost wrote:
> On 28/05/2017 00:04, Robert Ramey via Boost wrote:

>> And it's not because boost developers are ignorant of modern C++. That's
>> just wishful thinking on your part.  It's on you because you bad decisions.
> 
> Well, an ad hominem attack had to happen at some point.

This is not an ad hominem attack.  I'm criticizing your choices.  You've 
asserted that those objecting to your choices are ignorant of modern 
C++.  You've asserted that  "Some Boost developers are ideologically and 
irrationally attached to "how things are done around here".

I dispute all of the above assertions.  There is not evidence for them - 
how could there be as they are not true?  And even if they were true, 
they would in no way be an argument for the library, up ending boost via 
the inclusion of a single very small and simple library or anything else.

You've used these assertions as a way to discredit the arguments of 
those whom you disagree. This is wrong.  Worse, it is contrary to your 
own interests. Many of us want you to succeed as we want many to 
succeed.  Many of us much appreciate your efforts to contribute to 
boost, boost-gsoc, conferences etc., even though we disagree with most 
of your ideas. Many of us have tried to be constructive in attempts to 
make outcome a useful addition to boost.  Assertions such as the above 
diminish this reservoir of good will.  It is not to your advantage to do 
this.

> Let me firstly defend boost-lite, or rather the common support code
> currently called boost-lite but will be renamed at some point. It is
> quite frankly an amazing solution to the common framework and support
> needs of C++ 14 libraries.
This is an assertion that many of us question

But this was not my point or main concern.  It was that this is out of 
scope for a boost library to change boost in this way.  This is attempt 
to inject into boost a whole new way of doing things which many us don't 
have any faith in.  It touches on our usage of Git, CMake, and other 
tools which are questions which are orthogonal to the acceptance of the 
outcome library.

It lets new library authors get up and
> running with a new library very quickly, implementing best current
> practice build, packaging, test, dashboarding, version management and
> lots more without library developers having to think about any of that.

Again - Looking that documentation and code I fail to be convinced of 
that.

> It is free of legacy baggage, and saves me on a daily basis a ton load
> of time and hassle even amongst the three of my libraries it is used in.
> It also can scale out to an arbitrarily high number of libraries in a
> decentralised collection, far more incidentally than Boost could ever
> dream of precisely because of its decentralised design. I am proud of
> its design, the fact it confounds so many experts who study how it works
> is testament to the breath of fresh air it bring to modern C++ library
> design. I don't claim it to be perfect, it suffers particularly from
> immaturity, and hence I don't recommend that anyone else use it yet. But
> rather than attack it because it's different, you really should study it
> and learn from it because it has a lot of really great ideas and
> implementation in there. It could become the base of a major leap
> forward in standards aspiring C++ 14 and C++ 17 libraries precisely
> because we can finally dispense with the whole "one code silo to rule
> them all" philosophy.

Right.  I think this demonstrates my point.  We're not reviewing the 
source code of outcome here.  You're advocating a replacing boost with 
something better.  OK - but this it out of scope for the review of output.

> But let's return now to Outcome, as that's what this review is about.

<snip>

> Robert, but quite frankly, your opinion has no technical basis in fact.

LOL Right. It IS an opinion not a fact.  That's why we're having the 
argument.  Of course I would disagree that my arguments how no technical 
basis and you are free to so characterize them, but I'm doubtful it 
helps you in anyway.

Although it's implicit in my comments, I'll be explicit about my suggestion:

a) submit outcome in a way that looks like the rest of boost libraries 
so it would be evaluated by the same criteria that other boost libraries 
are.

b) Make you're own Nial-Boost-Lite repo which applies you're 
pre-processing stuff to all the boost library you want to include. It 
could, if convenient, include any or all of boost libraries as 
subprojects.  I would expect that you could find a way to generate this 
automatically from any C++ header source.  See how that flies.

And there is precedent for this.  I doubt anyone would be surprisd at 
this point that I created the Boost Library Incubator as my prototype of 
Boost 2.0 I can't say it's been successful in achieving this goal, 
though it has some useful value.

Robert Ramey