Re: [boost] Shouldn't both logging proposals be reviewed in the same formal review
Vladimir Batov wrote
Yes, it sounds very uplifting and inspiring... and I would agree with that whole-heartedly... if I considered Boost merely the place of purely academic exercise. For many "average" programmers though the Boost libs is first and foremost a product that they want to *use* uniformly throughout a project, many projects. In that light from the commercial deployment and project management points of view having 2 (or worse -- plethora of) functionally-similar facilities readily available is a nightmare as some will end up using one facility and some others will prefer another facility. Shared knowledge is fragmented (people rarely have time and capacity to know all), code reviews, maintenance are difficult, the ultimate product looks unprofessional due to inconsistencies (in case of logging configurations, formats, destinations will be different). It's not an imaginary situation -- our project for various reasons ended up using 3 logging facilities with the very real problems described above. Rectifying the problem now is an expensive and tiring exercise.
Do not get me wrong. I am all for creativity, innovation and healthy competition of ideas. However, all that does not have to be dumped onto the user to decide -- users often have no time, capacity, qualifications, freedom to make an educated choice. More so, users often *want* the gurus (and the level of the Boost community is most certainly considerably higher than the average) to make that educated choice for them. It's like one going to a financial planner for help and the planner dumping all the options on to that poor soul. Now that poor customer/user has to be a financial planner himself to make an educated choice.
It seems to me that you are trying to make boost into something its not. Boost has never been in the business of picking the best library in a particular domain. Its a place where promising libraries can live for a while, get used, and inspire new ideas and approaches. Some of these might make into the c++ standard. I do however agree with your larger point that boost does not SCALE well. Ten years from now, its highly likely that boost will become too large to manage. People will eventually start asking to distribute boost in parts, where the "core" libraries are separated from the "experimental" libraries. For boost to remain popular and successful, this issue will eventually have to be addressed. Fortunately, it probably does not need to be addressed for a few years.
On Thu, Nov 19, 2009 at 04:32:15PM -0800, Tom Brinkman wrote:
I do however agree with your larger point that boost does not SCALE well.
Ten years from now, its highly likely that boost will become too large to manage.
People will eventually start asking to distribute boost in parts, where the "core" libraries are separated from the "experimental" libraries.
Oh, I don't think this will take ten years. People are already asking for this, for the past number of years. :-) Especially people who are creating packages for distribution. http://lists.boost.org/Archives/boost/2005/09/93905.php http://lists.boost.org/Archives/boost/2009/01/147260.php http://sodium.resophonic.com/boost-cmake/1.40.0.cmake2/doc/modularize_librar... Cheers, -Steve
Tom Brinkman <reportbase <at> gmail.com> writes: ... It seems to me that you are trying to make boost into something its not.
From my mole-hill I feel that Boost has long grown out of its "academic/experimental" phase and went out to the masses. And the masses have different priorities/interests. Like the public did not exactly appreciate superior but "experimental" (late to the market with no sufficient support base) Betamax and favored VHS.
Boost has never been in the business of picking the best library in a particular domain.
Like it or not I do not believe it is how Boost is seen at large. Boost is known and valued for the high quality of its code. And the existing peer-review processes make sure it is continued tradition. Ultimately, a Boost library is the choice second only to the std. library. I.e. regardless if Boost has or has not been in the "business", the users made the choice that it is.
Its a place where promising libraries can live for a while, get used, and inspire new ideas and approaches. Some of these might make into the c++ standard.
Yes, it might well be how Boost started. However, IMO it has outgrown this vision years ago. If at large Boost was still considered an experimental playground for brainiacs (in good sense), then no commercial project would get close touching it. Instead countless number of commercial projects bet their money on Boost, i.e. its continued presence, relevance, quality, support, etc. (all the "boring" stuff that academic proof-of-concept projects can often afford not to be concerned with).
Ten years from now, its highly likely that boost will become too large to manage.
IMO it is already. However, it is still quite well managed and that allows people to deliver their commercial products with only Boost subsets.
People will eventually start asking to distribute boost in parts, where the "core" libraries are separated from the "experimental" libraries.
Isn't it already the case? Just put yourself into the shoes of a project manager facing overruns, deadlines, etc. I -- an excited s/w eng. -- come over and say -- there is a library that does what we want. Your first questions will be 1) quality? 2) will the lib. around long enough? 3) will the interface be stable enough? 4) etc. In that setting I suspect you'll steer clear from anything "inspirational-only".
For boost to remain popular and successful, this issue will eventually have to be addressed. Fortunately, it probably does not need to be addressed for a few years.
I'll probably have to disagree. I'd be more likely leaning towards "addressed now". All IMO of course, V.
participants (3)
-
Steve M. Robbins -
Tom Brinkman -
Vladimir Batov