From: Beman Dawes (beman_at_[hidden])
Date: 2001-01-05 14:18:05
In mid-December Dave Abrahams and I spent the better part of a day
discussing Boost related topics with Matt Austern, Andy Koenig, Bjarne
Stroustrup, and John Wilkinson. It's always interesting to hear how Boost
is viewed, and these are people active on both the C++ Standards Committee
and in the C++ community as a whole.
What follows is my view of Matt, Andy, Bjarne, and John's views, so is
bound to contain some inaccuracies. Hopefully I've got the major thrusts
right. Here goes:
* They are very supportive of what Boost is doing. They see free C++
libraries (and a web-site hosting those libraries) as very important, even
crucial, to the future of C++.
* Peer-review and wide participation are seen as key factors
distinguishing Boost from other efforts.
* Boost can be viewed as a sort of community or club, where the members
work well together. There is concern over how this can scale up as the
Boost effort expands both in size and scope. There is concern that other
efforts have degenerated into destructive warring factions and flame wars
as they grew beyond a certain size. [Dave and I explained that the culture
of Boost has so far been successful at discouraging self-destruction.]
There was discussion of Boost as evolving into a hierarchy (or DAG) of
communities, along domain lines.
* Domain libraries are of great interest, both in the sense of a view that
there is a user need for the libraries themselves, and the possibility that
sub-groups working on domain libraries may be a good way for Boost to
sustain future growth.
* C++ libraries are viewed as a spectrum, ranging from base libraries like
the traditional C++ Standard Library, on out to fairly obscure domain
libraries. Partially portable libraries were explicitly included in the
spectrum, with the example given of a threads library portable to Unix and
Windows but not to other platforms. The view was expressed that Boost
should consider libraries anywhere in the spectrum, and that the C++
Standards Committee might also consider a broad portion of the spectrum for
possible standardization (perhaps via non-normative Technical Report.)
* There was discussion of libraries with overlapping or duplicate
functionality. The specific scenario mentioned was library A providing 90%
of the functionality of library B, yet doing so with an interface and
implementation only one-third the size. Both were viewed as having a
* Several types of dependencies are viewed as barriers to wide acceptance
of Boost: Intra-library dependencies requiring all (or too much) of Boost
just to use a small portion, and tool-chain dependencies such as requiring
some Python, Perl, or GNU package, for building or using the libraries.
Thanks to Matt for putting the meeting together, and to Bjarne for acting
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk