Subject: [boost] Core libraries should separated from experimental libraries
From: Tom Brinkman (reportbase_at_[hidden])
Date: 2009-11-20 00:48:00
Continued from "Shouldn't both logging proposals be reviewed in the
same formal review"
Vladimir Batov said:
> 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
> 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".
I'm actually sympothetic with your point of view and you've certainly
made some strong points.
My experience has been similar.
Nevertheless, no matter how much you wish boost was something different, Boost's
mission statement is pretty clear. I dont see that changing anytime soon.
You should know that my favorite development library is Gnome (GLIB).
Its a very different library, its mission statement clearly states
Granted its a 'C' library, but its the library that my teams turns to
for most of
our programming needs. Its not community based like boost is. Not
thinking is done their, its all about being practical, minimilistic and writing
Boost is different. The libraries here reach for the moon -- some succeed.
Boost is where I come for inspiration and there has been some
absolutly brillant successes.
However, for practical day to day developer needs, I discourage doing too
much advanced C++.
Neverthless, boost needs to keep on pushing the envelope.
Functional programming is the future and boost is where you come to see
whats possible in that domain. I would hate to see that change.
If boost's focus is switched to addressing the needs of day to day
I would loose interest. I want boost developers to continue to reach
for the stars.
If "average" developers happen to find boost useful, of course they can use it,
but they need to appreciate where boost priorities have been and use
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk