[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: [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: Robert Ramey (ramey_at_[hidden])
Date: 2015-04-03 19:15:50

Eric Niebler-4 wrote
> 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.  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.

So my suggestion is:
a) start coding
b) discover that something like "another variant type" is needed
c) code "another variant type"
d) code a test ofr "another variant type"
e) debug at least part of it
f) make the documentation for it - refine the type requirements
g) go back and clean up the code and rerun the tests
h) by this time you should have boost build or make scripts
in order to test the damn thing.
i) submit it to the boost incubator and see if anyone else
can find complaints with "another variant type".  This 
get's to free testers, comments, corrections and critiques.

So far - you haven't done anything you won't have to do
pretty soon anyway - an now you've got some free outsourcing

j) pick he next piece and loop back to b)

The only thing missing is the Boost Review process. It's 
hugely time consuming.  It's useful - but not strictly
necessary.  What IS necessary to get your library considered
for the standard is a concrete implementation with real
world experience.  All of the above steps are un-avoidable.

So just submit it to the incubator and move on.  If Boost want's to 
review it - great.  If not - you'll still get most of the 
benefits. If you look at the library Safe Numerics in the 
incubator it has ONE review.  For whatever reason, the
author of that review put in some real effort.  On the basis
of his review I made a lot of small changes which will make
a huge improvement in the safe numerics library.  I don't
really need Boost, I need the help and infrastructure that 
Boost members provide.  They are not quite the same thing. 

I've skipped over one critical piece here.  That is picking the
right tools.  Picking the wrong tools can consume a 
huge amount of time which doesn't contribute to the
project.  I spent a lot of time evaluating options for 
development tools and made my recommendations in
the "Simple Tools" section of the incubator.  The set
I use and recommend aren't for everyone - but they do
work well for me.  Documentation in particular boils down to 
following a template for requirements and pre-conditions.
Naturally Tutorial and Introduction can be added later.

[note - off topic detour]

> 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".  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.  A more elaborate version
of something that isn't used is going to be used even less - not likely
a success in my book.

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!

> 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.

> 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.

> 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.

> 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
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.

Robert Ramey

--
View this message in context: http://boost.2283326.n4.nabble.com/Another-variant-type-was-peer-review-queue-tardiness-was-Cleaning-out-the-Boost-review-queue-Review--tp4674046p4674108.html
Sent from the Boost - Dev mailing list archive at Nabble.com.