Re: [boost] Boost Incubator Status Report

Subject: Re: [boost] Boost Incubator Status Report
From: Robert Ramey (ramey_at_[hidden])
Date: 2014-11-09 11:36:41

Rob Stewart-6 wrote
>>b) The above preclude the usage of documentation tools - 
>>specifically DOxygen which cannot support the creation of
>>documentation in accordance with a) above.
> 
> What's wrong with the tparam attribute?

I didn't know about this - I'll take a look at it.  When I looked at
DOxygen, I concluded that, though it might be possible, it wasn't easy to
create a page describing a concept.  Indeed, I've never seen DOxygen which
included concept pages or description of template parameters.  If you have
information/experience with this, 
feel free to add that information to the page in the Incubator where I
discuss my impressions of various documentation tools in the context of
Boost quality library development.

>>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.
> 
> I assume you meant to write that template parameters should be checked at
> compile time, in which case I agree. Unfortunately, the tools we have for
> that are awkward presently. We're awaiting concepts.
> 
>>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.
> 
> When possible, I agree. Unfortunately, the use of BCCL can change the
> characteristics of a type such as making an otherwise trivially copyable
> type non-trivially copyable.

This is news to me.  Assuming this is true - it's easy to use static assert
to get the same effect. My
point is - Don't wait for language support - start using what we already
have.

>>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
> 
> There is certainly room for the niche libraries you mention, since they
> won't be standardized.

I believe that the idea that the idea that every good library should be part
of the standard is
a bad idea.  Basically it can't scale and is likely reached the end of the
road.  We've already
made C++ so large (by requiring libraries) that we're down to 3 suppliers of
C++ compilers.
I don't see hope for new entrants - which we used to have.  Coupling the
language to libraries
has a huge downside.  Admittedly, accepting Boost libraries into the
standard has been a huge
boon to Boost.  But let's not get too stuck on that.  Use our credibility
and imprimatur to fix
the real problem - a world inundated with crappy, fragile, opaque software
that is so bad
people keep more of it.

> To your point of libraries "for the rest of us", one way that Boost causes
> itself problems is by our dissatisfaction with simpler designs. We're
> enamored with more esoteric designs. The imposition of templates when
> polymorphism would suffice, even if suboptimal, turns off many, the STL
> notwithstanding. Perhaps we need to encourage both kinds of libraries.

I absolutely agree.  I want to take this head on.

a) encourage better documents.  I believe that one reason we have over
elaborate designs which
lose sight of the ultimate purpose is that we don't insist on readable
documents and clearly define, orthogonal, de-coupled concepts (not the C++
concepts - but in the real sense of "concept).

b) we need to upgrade our deployment to permit subsets so that components
can be dropped without a huge
trauma.

c) we need to permit the creation of better components which might compete
with existing ones.  We need to look more like silicon valley rather than
downtown detroit.

> The other difficulty is that many companies are pleased to use high
> quality, free libraries, like those from Boost, 

Everyone likes free stuff

> but are reluctant to permit sharing those created in-house. 

Often because they don't want the world to see how crappy their code is. 
I've done work or a fair number of companies, and I never seen any code
which would meet the admittedly low bar of the Boost Inclubator - much less
for Boost itself.  That's why most of are here - because it's a place where
doing a good job is actually appreciated.

> The result is that many potential additions to Boost and, ultimately, the
> Standard are excluded.

And I hope the incubator will be a place which can promote and enforce
software quality even for
C++ software which for one reason or another isn't not headed for the
standard.  There is lots of
stuff that is really good - but wouldn't really fit in the standard.  Boost
Spirit?  Serialization? I doubt it.
Safe Numerics?  I think this should be in standard 15 years ago - but it
doesn't seem to create much
interest.  Looking forward - lets focus less on the standard and more on
rolling back the tide of 
crappy software that we're drowning in.

Robert Ramey

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