|
Boost : |
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk