Look, I'm not arguing that the library name is everything you need to know
about the library. I'm just saying that informative names really do help to find what you need.
How about Boost.Any? For the uninitiated, that could contain smart pointers. I look at the current names. Only a very few give me the enough information to know what they are for. What is assign? What is enable_if? What is parameter? asio? ref? variant? mpl? units? optional? etc. I wouldn't know by just the names!
Some of them are quite telling (iostreams, variant, filesystem, datetime, threads, function, program_options, serialization, should I go on?). At least, more telling than Qi. And I repeat myself, the name does give a hint on the library purpose, and I find it useful.
I'm not sure what exactly you are trying to convince me in. Is it that library names are irrelevant to their domain? Well, we could name libraries like GUIDs, at least we would have world-wide unique names. Do you think it would make life easier for users? Seriously, I'm not sure what we are arguing about.
If I was looking for a particular library in Boost. I'd look at
the categories. It's a shame that the current web interface lost this very useful page:
http://www.boost.org/doc/libs/1_37_0/libs/libraries.htm#Category
It can be many things, but it definitely isn't a library of smart pointers,
is it? On the other hand, Boost.SmartPtr is most likely what I'm looking for - therefore I will put more attention to it (read the docs, for a start).
Look, I'm not arguing that the library name is everything you need to know about the library. I'm just saying that informative names really do help to find what you need.
Obviously, having a simple, denotative name for a library is a good thing, but it's only really effective when the name can succinctly describe the features and functionality of the library. It's also easier, when those features are limited to a few well-known abstractions like FileSystem, ProgramOptions, Graph, etc. This arguably isn't the case for Joel's work. The breadth of abstractions represented by those libraries (DSELs, Parsing, Generating, etc.) aren't necessarily best described by a single term. In such cases, it's probably better to pick a neutral name (Spirit, for example) than to pick one that could be misrepresentative or misleading. I think the crux of the problem is not really the name of the library, but the ability to associate a library with a task. I think that Joel is right that it's a presentation issue. The documentation index is just a flat listing of libraries organized alphabetically, which is kind of an arbitrary presentation and not especially conducive to this kind of task. The category listing is substantially more useful in these regards. I would argue for moving this to the top-level documentation page or providing a very obvious link to it. Perhaps there are even better presentations for the breadth and scope of Boost libraries. Andrew Sutton andrew.n.sutton@gmail.com