Re: [boost] Re: Customer Friendlier Boost Installation

From: Jason Earl (Jason_at_[hidden])
Date: 2005-05-25 10:23:01

Ditto, I completely agree with everything below...

On 25 May 2005, at 16:02, Oliver Kullmann wrote:

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

I think some people seem to see me as anti GUI / pro command line. 
You've hit the nail on the head. GUI's seem to destroy understanding. I 
can't bear using GUI's for most of the web programming because it just 
tries to hide too much. At the same time tools like vi are just anti 
productive to my work due to the learning curve. A simplified build 
process is what's needed

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

A wiki would be excellent. One of the nice thing I like about the PHP 
documentation is that users have added comments over the years stating 
various gotchas they've experienced.

> Oliver
>
> _______________________________________________
> Unsubscribe & other changes: 
> http://lists.boost.org/mailman/listinfo.cgi/boost
>
>