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

Subject: Re: [boost] Core libraries should separated from experimental libraries
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2009-11-20 17:26:43

Tom Brinkman wrote:

> However, for practical day to day developer needs, I discourage doing too
> much advanced C++.

What is considered advanced? Is it shared_ptr/weak_ptr? Is it 
Boost.MultiIndex or Boost.Spirit? What would you suggest to use instead 
of these tools that I employ on almost a daily basis? Would my code be 
better in any way had I written all these tools in C again and again? 
Sorry, I don't think so.

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

C++ is good because it allows to use different programming concepts, and 
functional programming is only one of them. Limiting yourself to only 
one paradigm in C++ seems unwise to me.

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

Well, programming is a practical art. Boost is not a playground for a 
bunch of C++ gurus that are being bored. There are no libraries in Boost 
that "reach the stars" without a pure boring average task to solve 
behind it. Every library is intended to address practical needs of 
developers, otherwise it is no more than a useless junk.

Boost is good because it addresses a diverse spectrum of these tasks, 
and often does it in the most elegant way. Yes, in many ways it's 
experimental and innovative, as it often introduces nonstandard 
solutions and pushes compilers to their limits. But that being said, it 
_is_ intended and _should_ be used in the wild, including commercial 
software, because it's the only way to verify whether these solutions 
are actually successful or not. That is why I see Boost support 
(including documentation, fixing bugs, simplifying deployment, 
maintaining API stability, etc., etc.) to be one of the top priorities.