Re: [boost] C++ Manifesto

Subject: Re: [boost] C++ Manifesto
From: Paul Baxter (pauljbaxter_at_[hidden])
Date: 2009-09-10 17:32:42

Hi Christian

< Some extracts that ring true with me, my emphasis applied >

> I'm sorry. I don't think that Spirit is excellent C++. I think it is
> terribly clever C++

> I feel that C++?? is becoming just that. It doesn't matter that I can
> (eventually) understand the latest boost library, or the latest boost
> technique. What matters is what is the best way to write efficient code?

> When C++ is no longer the best way (and yes, that is a "when" not an 
> "if"),
> I would like to think that I am open-minded enough to be on that wave. Is
> that time sooner rather than later?

> I for one use foreach, shared_ptr, unordered, mpl, some fusion, and other
> bits and pieces. No-one in my team uses anything other than foreach and
> shared_ptr - and there is a lot of confusion I have to deal with relating 
> to
> their use of weak_ptr<> and locking etc with that.

> What do you use?  Which parts of boost are good to use with least impact?

> I am
> clearly frustrated with the potential of both boost and C++ in general.

> it makes me wonder if C++ is really what the real-time world needs.

I enjoyed and sympathised with pretty much everything you wrote.

I want to separate the C++ aspects from the Boost-specific ones.

C++
At present I'm not sure an alternative language exists that is mature, cross 
platform with an appropriately large, diverse, supportive community to 
provide programmer support in terms of tools, skills availability.

I also still shudder that many advanced techniques rely on an enhanced C 
Preprocessor for their magic. If we want compile time and runtime behaviour, 
a language ought to support both, without clunky but clever (albeit mostly 
hidden from the user) techniques.

Regarding the ecosystem surrounding a library, I compare C++'s progress with 
languages such as Python and see C++ as a poor relation in terms of tools to 
solve real world problems.

Boost
The focus does seem to be on creating new and novel techniques rather than 
solving problems or providing cookbooks on how to use these tools to make 
things easier. Arguably Boost was looking to the wider community and user 
base to develop the 'user guides' while library developers have a different 
agenda, focussing on the best interface and implementation.

IMO the C++ standardisation process in general and Boost by association may 
suffer from an academic outlook that prefers to deliver well-crafted items 
years too late. Boost was supposed to be a test bed and experimental ground 
but still tries to be too perfect in creating the ultimate library in each 
area.

I'd prefer to see more support, mentoring and advice and a shelter for 
promoting and improving many more libraries. Perhaps a second tier of 
toolkits that let evolution sort out more of what is right for programmers? 
By this I know we have an area for such libraries, but what web site support 
do we have to 'advertise, extol or document' such fledgling libs? Perhaps 
more of the web site could provide pointers to such libraries?

As an example, consider the library 'property tree'. Its interface and 
implementation weren't and aren't perfect but they solve a real-world 
problem in the absence of an alternative. There was a lot of debate that an 
imperfect library perhaps shouldn't be part of Boost. Thankfully it got 
accepted and thanks to Sebastian for moving it forward recently.

Boost should support and encourage these kinds of libraries even if perhaps 
not candidates for C++1X material.

Paul