Below follow some thoughts on why a potential Boost math library ought to be implemented within C++ - if not from scratch, then with the help of existing C++ libraries such as Blitz++. I don't think I adress any of Tom's discussion points very directly, but overall I would say I agree with him that there is a lot of potential for new libraries in the area. I think it's fair to say (?) that there are more mathematicians than computer scientists in the world. Within computer science alone, we've managed to devise a great number of languages and several of them are in common use: C, C++, Fortran, Java, Pascal, Basic, Python, to name a few. Assuming all these languages provided equivalent math functionality, all of them would likely attract mathematicians, the same way they already attract computer scientists. So, why shouldn't we be able to bring a large number of mathematicians to C++? The only reason, so far, is probably just lack of tools ("If you build it they will come" as Deane Yang put it). Many (if not the majority of) projects are not purely mathematical, but perform many tasks where scientific computing plays one role. Once you choose C++ for some reason (John Philips names many reasons), I think most people agree that it is much less hassle to stay within the language if you can, rather than hiring FORTRAN programmers and trying to make everything link together. Thus, even if implementations exist for other languages, I think one in C++ is worthwhile. There's been some discussion on whether to just provide wrappers to other libraries, or to implement them from scratch. At the same time, the library is viewed in the perspective of something that might end up in the language specification. That assumption does not quite mix with the wrapper discussion. Since a language specification would only define the interface, the use of FORTRAN libraries or whatever in the core would be at std library vendor's discretion. However, in addition to the interface, the Boost community provides a reference implementation. The question is, would we want this reference implementation to require external compilers for other languages? Furthermore, if the interface is not proven to be implementable efficiently in C++, can we be sure that it is at all possible? I think being able to implement 99% of the language specification within the language itself is important. If such a goal isn't met, we would essentially limit C++ to platforms that also provide the other languages needed. I don't think it would be a defeat to show comparison graphs where FORTRAN turns out to run faster than C++. There are many times when other things are important than that extra bit of speed. Speed of implementing the algorithm, for instance. If I see graphs where FORTRAN is, say, 10% faster, I might just decide it's worth losing 10% speed in order to gain something else. /Mattias