On 2 Apr 2015 at 17:33, Eric Niebler wrote:
On 4/2/2015 11:06 AM, Niall Douglas wrote:
These endless discussions about how best to implement Boost's future wouldn't be happening if every top tier new C++ library was always assumed de facto by its author to eventually be destined for Boost. The fact that so many top tier authors, including so many formerly with a big presence here, no longer bother with Boost I think speaks volumes about what's gone wrong here with how library quality is assessed here.
Speaking strictly for myself here: the reason I haven't pushed to get my recent open source contributions into Boost is not because I consider my code of higher quality. If anything it's quite the opposite. Getting a library into Boost is so daunting and time-consuming that -- at least for the work I'm doing these days -- I just don't have the time. It pains me to say that. I don't have the time to produce Boost-quality documentation and to exhaustively test everything. Concepts are coming. It's not hard to see that the STL will need a ground-up rewrite. I needed to get on the Concepts train, and it was going to pull out of the station with or without me. It would take half a year to make range-v3 Boost-worthy. By that time, I'd have missed my chance to get ranges baked in from day 1.
I absolutely agree. I'm just out of six weeks of staying up till 5am each night after the family went to bed to get AFIO v1.3 out the door. That's because it had to be Boost peer review quality as it's in the review queue. I ended up dumping perhaps 200 hours in getting a feature complete and what I would have called "finished" library into a Boost peer review quality library. That's 200 hours I did not bill hourly to clients for, and as a consequence my earnings have taken a big hit for the past two months. If I were still working at BlackBerry, I am highly unsure if regularly releasing a Boost library is compatible with not getting divorced and/or not fired.
Maybe that speaks to Boost's review process, but it doesn't speak to the quality of Boost's code, which I consider very high.
I realize that doing an end-run around Boost to get ranges in the standard is deflating for everybody who has worked to make Boost what it is. That includes me.
And this is where the nub lies in where my vision of Boost 2.0 differs from Robert's. I want to see an incrementing score automatically generated such that when you Eric throw caution to the wind and accidentally dump three days of work into your potential Boost library because something in it bugged you, you immediately see a jump in your library's rank. If Boost programmers are like any other type of human being, that immediate gratification has highly positive effects on you repeating that misallocation of your time sooner rather than later. Especially as most of the 200 hours invested in getting a library release Boost ready is drudge work - soak unit testing for 24h, writing yet more unit testing, spending three nights consecutively in the debugger tracking down some rare unrepeatable segfault, writing yet more tutorial toy use examples. That sort of thing. All stuff which needs to be rapidly rewarded psychologically, else you'll avoid it even more. That tight feedback loop spurring people on psychologically to accidentally do better can't happen when human review is involved. Especially when people are waiting *three* *years* to get a review - though I am very glad Emil finally has a review manager as a result of this thread. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/