Re: [boost] Re: Customer Friendlier Boost Installation

From: Oliver Kullmann (O.Kullmann_at_[hidden])
Date: 2005-05-25 10:02:04

>   But if this was my first look at boost, I'd delete
>   it right away. Seriously, on this platform are
>   millions of C++ users that only heard very vague
>   rumours of C++ being standardized -- if they heard
>   about it at all. Those don't see much benefit it
>   smart pointers, consider the MPL to be black art,
>   and can't be bothered if it isn't really easy to
>   use.
> 
>   Schobi
> 
> -- 

But for these "millions of C++ users" Boost is not the right
choice. The exciting thing about Boost is that it is Avantgarde,
a good deal of interesting research(!), and not compromising
on quality. That's at least my understanding of Boost.

Sure, it would be nice to have this additional layer for beginners,
but that simply seems not to be feasible.

Sure, documentation of Boost can be improved (and the installation guides
as far as I know them are really not enough (I say this as a Linux
user)), but that's true for ALL existing software. It's just hard
to write about technical material, and, as I know it from our students,
for example almost all computer science students have to be considered
as near analphabets, so it's not so easy to get the documentation written.
(But GUI's are at the root of that problem: They destroy understanding.)

Here comes one proposal: If it would be easier for boost members to
edit existing documentation, then at least I could contribute quite 
a bit. But I mean "really easy", for example a wiki with the current
documentation, where one can just goes and change it (and there is somebody
responsible for each (sub-)library); this could really improve documentation
a lot. (One should have as a general guideline, that additions are conservative,
that is, they only extend and correct the given text, but they do not eliminate
something (because one doesn't like the style etc.). And my focus here is really
on the *text*, which quite often assumes some common ground, which more often than
not is not given.)

Here one example (about documentation in general): I know of one MSc project of a
colleague, based on Spirit, which nearly failed because the student didn't have
the right understanding what Spirit really was supposed to do (that "recursive
decent parser thing"), and also I fall into the same trap (but it only cost me
a few hours). So an easy thing would be to go to the *current* Spirit documentation,
and add at one or two places a few warnings. This could help a lot. But first writing
an e-mail, explaining all this, etc. costs too much time. Just adding these sentences
on a wiki, that should be it, and the maintainer then is automatically alerted.

Oliver