Re: [boost] Boost Incubator Status Report

Subject: Re: [boost] Boost Incubator Status Report
From: Robert Ramey (ramey_at_[hidden])
Date: 2014-11-08 20:01:25

Edward Diener-3 wrote
> Having worked for approximately 30 different companies in my career as 
> largely a computer programming consultant I am well aware of many 
> programming shops, even within major corporations, who have no clue 
> about reusability of software. 
> 
> There is absolutely nothing Boost can do 
> for such places, because the general understanding of program creation 
> is so low and in the hands of programming managers and their like who do 
> not understand programming design in any way.
> 
>  I have fought too many 
> losing battles with companies for which I have consulted, trying to 
> convince people whose programming talent is low, that using reusable 
> libraries such as Boost will make it easier to accomplish their goals. 

LOL - you're preaching to the choir here.

But I don't think things are totally hopeless and I think Boost CAN
improve the situation.

I remember when STL became available.  There was a lot of negative
reaction due the to fact that it had a lot of unfamiliar concepts
such as function objects, iterators, and others.  But slowly it
did get taken up.  One reason for this success was the quality
of design of STL (not perfect but as good as C++ permitted),
and the quality of STL documents (SGI website, STL Reference,
(Musser),  and Scott Meyers Effective STL.

To a small extent the same has happened with
Boost and things will likely improve at least for those parts of
Boost incorporated in the standard.  Books like Boris Schaling's
will also have a positive effect.

In my view, the single most effective Boost could do is to raise
the standards for documentation of Boost libraries and help
library authors meet these standards.  This is a primary focus
of the Boost Library Incubator.  There's one big problem however.
There isn't a strong consensus on what high quality C++  library is.
I've tried to make the case for my viewpoint in the incubator 
(Advice, Concepts) And I think this has helped some - but still
there are lots of people who I haven't yet been able to sway
to my point of view.  This is a work in progress.

TL;DR;
For reference - I'll include a short summary of my views on this
subject:

a) All template parameters type requirements should be explicitly
documented.
b) The above preclude the usage of documentation tools - 
specifically DOxygen which cannot support the creation of
documentation in accordance with a) above.
c) All template parameters should be at compile time so that that
the compiler will trap when a user attempts to use a type which
does not meet the documented requirements.
d) C++ does not currently support the above in the language 
itself.  But this is no reason not to check the parameter types
using Boost Concept Checking Library or other means.

It's not a lot more complex than that - and would seem to me to
be uncontroversial - but there has been a lot of resistance to this
point of view.  I'm still working on that.

As an example, I will site the Boost Units library.  Not that I'm not
picking on this particular library, there are many examples in Boost, but
this one is close to my heart. This is an incredible piece of work.  
Usage of this library would be hugely beneficial in many, many programs.  
But the documentation of this library makes it very, very hard to 
understand how to use it.  A naive programmer cannot simple spend an hour
looking over the documentation and get his own simple example
working.  He then moves on - for good reason.

For Boost to continue forward - it has to appeal to the "rest of us".
That means 
a) more libraries, 
b) of much higher quality,
c) supporting more niches areas,
d) which can be written by more people

That is the motivation and purpose of the Boost Library Incubator.

Robert Ramey

--
View this message in context: http://boost.2283326.n4.nabble.com/Boost-Incubator-Status-Report-tp4668747p4668837.html
Sent from the Boost - Dev mailing list archive at Nabble.com.