Subject: Re: [boost] Core libraries should separated from experimental libraries
From: Stefan Seefeld (seefeld_at_[hidden])
Date: 2009-11-20 13:55:59
Sorry for jumping into this thread, but since it has taken a different
twist now, and since I have some rather strong feelings with respect to
the points you are making here, let me try to address them.
In particular, I find the view that you express here very narrow-minded.
You construct a false dichotomy:
On 11/20/2009 12:48 AM, Tom Brinkman wrote:
> 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.
There is definitely more than functional programming in the future. The
trend in hardware design certainly raises a lot of challenges to
software programming as a whole, and it isn't clear what programming
paradigms will yield best results.
> If boost's focus is switched to addressing the needs of day to day
> "average" programmers,
> I would loose interest. I want boost developers to continue to reach
> for the stars.
This statement is what I disagree most with. You seem to suggest that
the only reason not using boost is because users aren't qualified enough
for it. Don't forget that boost's (original) mission statement
explicitly is (was) to be a platform for library standardization, which,
by definition, addresses 'day to day' needs.
> 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
> it appropriately.
And this view I find particularly narrow-minded and condescending. The
issues I see with boost have (almost) nothing to do with 'average' vs.
'star' developers, and how much expertise is required to get the most
out of boost (though it certainly plays its role).
A much bigger issue I see with industry acceptance is code stability
(not in terms of bugs, but in terms of backwards compatibility),
scalability (boost is growing bigger and bigger, and very few people
seem to care about how sustainable this growth is. It's just not true
that boost users only pay for what they use), or maintainability (what
if I need a bugfix from boost-1.(x+1), but without loosing compatibility
with boost-1.x ? What about packaging issues ? I build software that
runs on a wide variety of platforms, so the nightmare of figuring out
the platform-specific boost dependencies and build issues for all of
them is all mine.)
Finally, the point triggering your comments was about *core* libraries.
Those have been in use for quite a while, and have thus stabilized (if
not even being integrated into and or obsoleted by the upcoming
standard). Thus, I think the dichotomy is fake: Releasing core
components of boost stand-alone (which all that implies: independent
release cycle, independent packaging, etc.) does not prevent other
"bleeding edge" components to continue to evolve. Quite the opposite,
-- ...ich hab' noch einen Koffer in Berlin...
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk