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

Subject: Re: [boost] Core libraries should separated from experimental libraries
From: David Bergman (David.Bergman_at_[hidden])
Date: 2009-11-20 14:11:05

On Nov 20, 2009, at 1:55 PM, Stefan Seefeld wrote:

> On 11/20/2009 12:48 AM, Tom Brinkman wrote:

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

You think all developers are at an equal footing? In my limited experience, only having worked in this field for 30 years and led a few hundred developers in total, there is a huge difference between Good and Regular developers. As big as between the a junior nurse and an experienced brain surgeon.

If you agree with that, I have another question for you: do you think the exact same tools work equally well for people at these different levels? If not, it is at least fair enough to reason about the intended target of Boost.

I fail to see how (i) point out that huge difference in skills (and cognitive performance) between developers, and (ii) suggest that the tools provided by Boost should be for the upper layers, is condescending.

So let us get back to the basic question: who the heck is Boost for and for what use?

Honestly, real C++ is not for junior developers. Period. Part of the language can be used by a junior developer, and even part of Boost (shared_ptr + some collection types and traits), but most (of C++ - C) cannot.

> The issues I see with boost have (almost) nothing to do with 'average' vs. 'star' developers,

You think that distinction is not real?

> and how much expertise is required to get the most out of boost (though it certainly plays its role).

Yes, agreed. It does play a huge role, to get outside of shared_ptr and a few collection goodies.

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

I might agree here. The danger I see, although I have been a game developer in a few early lives of mine, is the domain-specific proliferation in 3D and numerics. I have posted about this before. These do not solve day-to-day needs for most developers, not even in a particular skill layer.

If the truly domain-agnostic would be considered Core, I would agree with Tom. No matter how complex the notions in those libraries are.

/David