Re: [boost] [library-incubator vs Developer's list] was Ease commenting (Was: [safe_numerics] questioning the basic idea)

Subject: Re: [boost] [library-incubator vs Developer's list] was Ease commenting (Was: [safe_numerics] questioning the basic idea)
From: Felix Uhl (felix.uhl_at_[hidden])
Date: 2014-11-19 14:06:08

Robert Ramey wrote:

>> True, but it doesn't immediately raise a discussion - a message posted 
>> here gets seen by quite a few people, hopefully some of whom will be 
>> motivated to respond.

> Damn - I just can't win here!


As I said in a previous post, this is the problem of the incubator, a lack

of community. I know that it would be a lot of work, but your best bet

is to build on the large mailing list community that already exists.


> a) Boost (I believe) was conceived as a way to support C++ with expanded
> libraries
> which would eventually enter the standard.
> b) It has largely fulfilled that purpose.  Making the standard a lot bigger
> will make
> it every more difficult for vendors to supply a conforming implementation. 
> So I don't
> think the standard library can grow a lot more.


Thoughts like that seem to be preliminary to me. We shouldn’t stop thinking

about new facilities.

But I agree that boost is not the “Soon on std” it was a long time ago, and I think

this is the general consensus now.


> c) But C++ still needs a lot of help.  It needs a lot more libraries most of
> which are
> too special purpose to be suitable for inclusion in the standard.  And the
> number of
> these libraries is large - on the order of 500.  This has to be the goal of
> Boost 2.0


This is a huge point of discussion, but probably not suited for this thread.

The future of boost is a controversial topic, though.


> d) This list can't do this job
>  1) 500 libraries would drown this list.



I agree that this mailing list is not suited for a larger number of libraries,

it is already pretty crowded.  I personally like the layout of forums,

the ability to subscribe to threads and have subforums for different topics.

We already have sublists for larger and more widely used libraries, so 

that’s something.

However, I don’t think the incubator would handle that number of libraries well,

either. Something prepared for that scale will probably be hard to implement

in wordpress. For a plan this huge, you need to form a team of highly skilled

professionals that can envision, plan and execute such a project.


>  2) the discussions on the list are extremely useful and should be
> preserved in an easily accessible way.


Again, forums do that quite nicely.


>  3) There needs a way to pay for this development - boost has no way to do
>  this.


I’m not here since a long time, but from what I could tell, boost is

not based on voluntary work entirely, is it?

Still, you’re probably right in the way that boost encourages high quality

libraries which are above the standard of many company-internal code,

and that the countless hours of work for a library that is well documented,

written and tested should be compensated for.

For me, just the knowledge that other programmers, probably even companies,

will use my code, is quite satisfying, but I’m only writing a small header-only library,

something you could still consider a hobby.


>  4) This needs a lot more library writers.
>       i) But most programmers don't know how to prepare a boost quality
> library: code, tests, documentation, etc.


I don’t think boost has to nor needs to train new programmers. There are good

programmers out there, and some of them may have written code for their work

that could become a good boost lib, if they had time to flesh it out.


>       ii) Most library writer need some hope of compensation to justify the
> time spent.


Yes. Especially considering that boost has high standards for code quality,

you can’t just submit an interesting prototype and call it a boost library.


>       iii) All libraries need testers, critique, feedback, etc.  Boost can
> only do that for libraries in review - and we can't review the candidates we
> already have.  And we don't have a mechanism other than this list for
> dealing with this outside of the review.  In a nutshell, the developer's
> list can't scale the way I think it has to.


As noted previously, I agree with you there.


---

Felix Uhl


PS: Robert, you really like writing lists of stuff, don’t you? ;-)