-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of David B. Held Sent: Wednesday, June 02, 2004 9:13 PM To: boost@lists.boost.org Subject: [boost] Re: Re: Boost Mathematicians
"Reid Sweatman" <drunkardswalk@earthlink.net> wrote in message news:!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAAQ16IR/xA0B GKJURFU1QAAAKJAAAQAAAArLDup9m3ck+fnQ8diyZEOwEAAAAA@earthlink.net... [...] I'd say (speaking as a soi-disant mathematician) you also need to find ways to overcome the perception that "other languages do it faster and/or more accurately." [...]
And that's not the case I would make in this scenario. I'd say that it only makes sense to port all that code from other languages if C++ offers compelling reasons to do so. Just because it can be "just as fast" or "just as accurate" doesn't mean that we should invest all this time in it. Isn't it possible to call a FORTRAN library from C++?
There are many other languages that offer this feature or that feature better than C++. But at the end of the day, I have to say that C++ is the right choice for a lot of projects because of factors other than speed or size. And by that I mean things like installed code base, user support, platform support, etc. The fact that people have been writing scientific e in FORTRAN pretty much since the language was invented means that there is a huge installed base of tools for working with it. These are the kinds of factors I have in mind when I question whether C++ is the most appropriate language for this type of work. Yes, we surely *can* reinvent the wheel. But is it cost-effective? And isn't Boost all about *not* having > to reinvent the wheel?
For most libraries in Boost, I can see a clear and obvious benefit from providing that library in C++. But when it comes to algorithms, it is much easier to separate the interface from the >implementation, so it seems that we should at least consider simply providing C++ wrappers for implementations that exist in other languages. If there are clear benefits from reimplementing everything in C++, I'm all for it. I just think it's worthwhile to look at all the angles before diving in.
Sure, I agree. The motivating influence, I'd say, would be to have such a thing in the C++ STL spec, as that's the raison d'etre for Boost to begin with. If it's already out there, freely available in some other language, and there's no reason for wanting it in the spec, then sure, don't do it. Question is, is all of that true? And would it be of value to have it incorporated into the language spec? From my standpoint, yes. Others may not agree. Reid