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