Re: [boost] [Developing for Boost saves time]( was Re: Another variant type (was: [peer review queue tardiness] [was Cleaning out the Boost review queue] Review Queue mem)

Subject: Re: [boost] [Developing for Boost saves time]( was Re: Another variant type (was: [peer review queue tardiness] [was Cleaning out the Boost review queue] Review Queue mem)
From: Eric Niebler (eniebler_at_[hidden])
Date: 2015-04-04 19:36:43

On 4/3/2015 4:15 PM, Robert Ramey wrote:
> Eric Niebler-4 wrote

Eric Niebler-4? What happened to the first 3 Eric Nieblers?

>> 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.
> 
> My view is that if developing for Boost is taking extra time, you're 
> doing it wrong.
> 
>> I don't have the time to produce Boost-quality documentation.
> 
> If producing Boost quality documentation is taking extra time, you're
> doing it wrong.
> 
> I'm not being facetious here.  I think that one can't really verify
> that his library is correctly conceived and design until he tries
> to document it.  

I completely agree. And I have been documenting it. I have on my machine
a 170 page proposal that I intend to submit for the next committee
meeting. It exhaustively documents a not insignificant fraction of
range-v3. It represents about 6 months of work. Trouble is, it is about
as usable as documentation as any other part of the C++ standard. Which
is to say: not at all.

Writing Boost documentation would be a whole other 6 months. You see
choice I had to make.

> In our world that means as clearly specified
> set of type requirements along with any other pre-conditions.
> The problem is that if you leave this until you're done, you
> discover that you've wasted a huge amount of time developing
> something that you don't really use - or could have been
> simpler. 
> 
>> and to exhaustively test everything.
> 
> If you're not writing the test as soon as you write a component
> how do you debug it? - or if your code doesn't need debugging
> (because its Eric Niebler I'm addressing here) How is anyone
> else sure it doesn't need debugging?  You can't really progress
> without a test.

I was selling range-v3 short. It *does* have fairly extensive tests. I
was able to crib much of them from libc++.

<snip>

>> Concepts are coming.
> 
> dream on. The current versions looks to be captured in the "concepts lite"
> paper which is quite ill-conceived in my view.  I have a huge problem
> with what I presume to be the canonical example they've chose
> "sortable".

The "canonical example" they chose is the STL. See here:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3351.pdf

Despite what you think, concepts are real and they're coming. If you
dislike the Concepts Lite approach, you're not alone, but that's what
we're getting. It's certainly not all that C++0x concepts were, but
there's some good things about that, and having built a non-trivial
concepts-based library (range-v3 uses a Concepts Lite emulation layer),
it's really not bad. Range-v3 would be impossible without something like
concepts, and real language support will help immensely, IMO.

> I talked about that at CPPCon.  But besides that,
> we've had a simpler and "good enough" implementation of type
> requirements checking in the Boost Concept Checking library for
> over ten years - and hardly anyone uses it.

Maybe that's because it has usability problems, and doesn't actually
solve the problems concepts are intended to solve. You can't do
concepts-based overloading with Boost.Concepts, for instance.
Boost.Concepts gives only hard errors.

> A more elaborate version
> of something that isn't used is going to be used even less - not likely
> a success in my book.

<shrug> Predicting is hard, especially about the future.

> But then we never take any kind of poll about which features/libraries
> are actually used by C++ programmers.  So we don't really have any
> idea what's really successful.  This is perhaps a good thing.
> 
> [end detour]
> 
> 
>> I needed to get on the Concepts train, and it was going to pull out of the
>> station with or without me.
> 
> LOL - no way - it's guys like who are actually driving the train!

The Concepts TS happened completely without me. Concepts TS 2 -- the
concept-infication of the STL -- was already being talked about. If it
seems like I'm driving the train now, it's only because I talked a good
game. :-)

>> 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.
> 
> at the risk of repeating myself, you won't save any time by trying to
> shortcut the process.

I won't repeat myself.

>> Maybe that speaks to Boost's review process, 
> 
> Factor the Boost review process out of the discussion.  Make a boost
> quality library and let the Review process take care of itself.
> 
> The main motivation for getting a library reviewed and accepted by boost
> is to get a certification of one's competence and accomplishment.  You
> don't need any more of this from Boost.  It wouldn't hurt, but you don't
> need it like the rest  of us.

Thank you.

>> but it doesn't speak to the quality of Boost's code, which I consider very
>> high.
> 
> It's variable.  Considering the whole library - not just the code - In many
> case
> it needs to be higher - a lot higher.

There's parts of Boost *I* would design differently. But that's not a
quality judgement.

>> 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.
> 
> I understand why people would look at it this way.  And I think they're
> drawing
> on the wrong lesson.  By skipping the Boost Review process, you're making
> a rational decision under the circumstances.  It's a sign that boost has to
> evolve to stay current and relevant.  How it has to evolve is something
> under
> active discussion. To me it's not deflating - it's inspiring!
> 
>> FWIW, if someone were to volunteer to polish the docs and tests and run
>> it through a review, I'd be overjoyed to see range-v3 in Boost. Ditto
>> for Meta.
> 
> well finish them off and submit them to the incubator.  Meta in particular
> would be interesting for a few reasons
> a) looks like you have it mostly done

Few docs. Few tests. The only reason it exists as a thing at all is
because Gonzalo factored it out of range-v3 and made a repo for it.

> b) it's small interesting component of current interest - C++11+ and MPL
> replacement discussion
> c) it would let you demonstrate/test and lend credibility to the incubator
> d) it's the most likely way you might get someone to take over this part of
> the project - see free outsourcing above.
> e) Under "suggestions for libraries" there are two suggestions.  Seems that
> Meta would fit in typlists - which I would prefer as library name as it
> dovetails better with A's book(s).  I would like a separate smaller library
> for metafunctions - but I'm not sure if you've got that factored out or not.

Meta is both typelists and metafunctions[^1]. They were separate, but
that didn't buy anything so I put them together.

I agree that Meta would be a good thing to throw up on the incubator,
and even to run through the Boost review process. It's a slightly
different approach to metaprogramming, and I would need the feedback and
usage before I could take it to the committee. (Range-v3 was different
since it's similar in principle to Boost.Range.) Unfortunately range has
eaten up all my time and probably will for a while.

[^1]: Meta doesn't have metafunctions per se. In Meta they're template
aliases and alias classes.

-- 
Eric Niebler
Boost.org
http://www.boost.org