[boost] Re: Divergent Paths in Boost?

From: Robert Ramey (ramey_at_[hidden])
Date: 2003-11-03 16:04:28

There is boost.

There's llots of other good stuff thats not in boost.  I use it
all the time - but its not quite the same.

Whats the difference?  The extremely high quality of boost libraries.
This quality is manifested in:

a) higher than average conceptual integrity in the design and usage
b) higher portability and adherenence to standards
c) better coding practices
c) better documentation

This higher quality is probably due to the fact that the number
of man-hours invested / line of code is probably much greater
than other libraries.  This is a direct result of the review procedure
and acceptance requirements.

I don't see how boost can maintain this level of quality without this
extra effort.  Given that its a huge effort o make such a library
it figures that boost will have a smaller number of libraries
and these libraries will be those that are more used more widly
(e.g. smart pointers, muli-threading, type-traits etc).

Of course, getting one's library accepted into boost is a source
of personal satisfaction and helpful to one's career. 

It is inevitable therefore that many more libraries are going
to be submitted to boost than will be accepted.

So the review/acceptance process will be "harsh".  The public
character of this process, makes it even "harsher" .

So inspite of the fact that commentary is very professional
and not at all personal. Its going to be painful.  So if want to
submit a library to boost you have be preparied for:

a) its very frustating to have to deal with a question/objection
from someone who gives a cursory look at some aspect of
the library and starts a thread that takes you huge amount
of time to deal with.

b) Its very frustrating to deal with objections that the library
submitted is not something other than what it is.  That, the
library doesn't do x, y, z . which is an entirely different
question than "is the library worthwhile as it is"

c) Its very frustrating to deal with someone who has his own
version of the library which he has invested a tiny fraction
of the effort required to even make a credible submission.
That is one's library which is ready to test is compared
against something that really isn't but "can be made to do that"

On the other hand, one will receive a large number of corrections
to one's own errors in code and documentation.  Also, one will
get a couple of very, very insightful observations on some aspect
that was previously completely overlooked.

I don't see anyway to make this less painful.  I mean its like
asking Is there a way to make brain surgery a more agreeable 
experience?

Slightly off topic but anyway. Here are a couple of miscelaneous
opinions.

Many libraries are not "formal" enough for my taste.  That is the
don't factor things cleanly enough in to separate pieces.  Granted
thats very hard to do - and impossible to do on the first pass.

Most libaries have not invested enough work in documentation,
examples, etc.  Sometimes a library has something automatically
generated.  This is of no use to me  - I can read the code myself.
The documenation has to give a better idea than the code itself
about what the asthetic aspects of the library which make it 
easier to understand and use.  

The documenation has to be pretty complete when the library
is to be used.  It can't be added afterwards.  This is because
in writing the documentation - especially a tutorial, one discovers
that the library has to be re-worked to make more sense.

A library can't really be evaluated unless it mostly complet
and works on a couple of compilers.  Same as above - making
changes to accmodate the "greatest common demoninator"
of compilers is going to feed back to the code, api, and documentation.

The question remains about useful code for which the effort
to get it officially reviewed/accepted into boost isn't justified.

The best place for this is the Boost Files section.  I use it 
all the time and find it very useful.  I would like to see it
upgraded so that one doesn't have to get a yahoo account
and that people can post comments/suggestions observations
regarding the package.  This would provide a "staging area"
where by ideas can be developed before being submited.  As
I said before, there are lots of ideas that are very valuable
but are not of wide enough applicability to make it worthwhile
to subject to the boost "treatment"  I have used the files section 
for this purpose and it has been very helpful - but it could be much better.  
BTW the sandbox is getting short of space.

My personal view is that the concept of a "Standard C++ Library"
is overrated.  I think they should have stopped with input/output
and let each library developer (e.g. STL) support his creation.

So as far as making a library, this isn't a consideration for me.

I can't understand how this message go so long.  Oh well.

Robert Ramey

David Abrahams wrote:

>One recent example comes to mind: Robert Ramey's serialization
>library.  While some of his reactions during the review seemed to
>support your point of view, I think his return with a new design that
>meets with nearly unanimous approval proves that the review process
>is working.

>The hard part about formal documentation is that (painting with a
>broad brush here), people don't read it.  Tutorials are of course very
>helpful, but if you supply one, many people will stop there.  I'm
>beginning to think it would be best to try adopting an "annotated"
>style of formal documentation, much like the original C++ ARM did, to
>help people navigate it... but that's just speculation.

>> Neither the sandbox CVS nor Yahoo serve the "experimental"
>> purpose.  The Yahoo files area is a place where lots of code
>> languishes 

>Probably a bad thing.

>> and there is no visibility on the web site for the
>> individual files/libraries in either the files area or the
>> sandbox CVS.  

>Probably a good thing.

Rob Stewart wrote

>> One recent example comes to mind: Robert Ramey's serialization
>> library.  While some of his reactions during the review seemed to
>> support your point of view, I think his return with a new design that
>> meets with nearly unanimous approval proves that the review process
>> is working.

>Wouldn't that review have gone better with the approach I've
>suggested?

.