Re: [boost] Core libraries should separated from experimental libraries

Subject: Re: [boost] Core libraries should separated from experimental libraries
From: Stefan Seefeld (seefeld_at_[hidden])
Date: 2009-11-20 13:55:59

Tom,

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, 
actually.

     Stefan

-- 
       ...ich hab' noch einen Koffer in Berlin...