[...]
Todd> My thinking about standards has shifted a bit lately. One of the
Todd> things I've learned from following the C++ standards effort is
Todd> that standardizing libraries can sometimes be the wrong thing to do.
Todd> (Note: I think that standardizing some parts of the C++
Todd> library is essential e.g. iostreams, strings, locales, etc.)
Todd> Why?
Todd> 1. Standardization kills a library's ability to evolve rapidly.
Todd> Feature turnaround becomes very slow: if you want to add something
Todd> to the library, you have to champion your ideas through years of
Todd> committee meetings, and then hound vendors to implement them.
Todd> 2. People may become frustrated with the slow feature turnaround rate
Todd> and implement their own extensions. The result is many versions of
Todd> the standard, all with different sets of extensions. This has
Todd> happened a bit with STL.
Todd> 3. Experimental features must be prematurely standardized, before
Todd> experience can produce a consensus on the "right way" to implement them.
Todd> Example: tensors in C++. We don't have a clue how to do these right
Todd> in C++ yet. Our first pass at them is likely to be unsatisfactory;
Todd> we'll probably need several iterations to get them right. A standard
Todd> would make it very difficult to iterate towards the right solution.
Todd> Another example: valarray<T> in the ISO/ANSI C++ standard. Lots of
Todd> people agree that isn't the right solution, even some of its designers.
Todd> But now that it's standardized, it's going to be tough (maybe
Todd> impossible) to chuck it out and start over again.
Todd> Maybe most importantly, who would implement a standard scientific
Todd> computing C++ library? Compiler vendors? Standard library providers
Todd> (e.g. Rogue Wave)? What would be the economic incentive for them to
Todd> do so? Scientific computing is a very small market segment for most
Todd> compiler vendors. And the standard library you propose would be
Todd> very expensive to implement.
Todd> Maybe defacto standards are a better way to go. Look at
Todd> how successful BLAS, LAPACK, IMSL etc. have been. They are portable,
Todd> widely available, and offer high performance.
I totally agree with these lines. In fact "C++ in numerics" is a too
young discipline, and we lack experiences. As Todd suggested, the best
thing we can do for the moment is to try ideas over again (LAPACK has
a long history) and not to cast in stone presumably immature designs.
-- Gabriel