From: Hubert Holin (Hubert.Holin_at_[hidden])
Date: 2004-06-15 07:20:17
Somewhere in the E.U., le 15/06/2004
In article <c9m4td$alu$1_at_[hidden]>,
"David B. Held" <dheld_at_[hidden]> wrote:
> "Reid Sweatman" <drunkardswalk_at_[hidden]> wrote in message
> > [...]
> > 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 is no guaranteed way to do so, and no guaranty that if the
call is allowed it will do what is intended.
You may also have to consider costs considerations. First, you may
have to buy an additional compiler (for instance if your C++ compiler
does not play nice with a freely available FORTRAN one). Then you have
to maintain software written in two language, one of which is not
exactly user friendly (to play devil's advocate, I will not say which
;-) ). This means to keep on staff people who still know FORTRAN.
Today, a sizable proportion of the people who use FORTRAN are those who
studied it when C was still on the horizon, but in ten years? In twenty?
Why would young people *still* want to learn FORTRAN? Latin may soon
prove more useful... If you have a large software which must still run
in ten to twenty years from now, are you confident you will find staff
schooled in that arcane knowledge by then? Even if such is the case,
will you be able to afford them? A quick buck now can mean a huge
If you are faced with a legacy program, written in a language you
do not know, and you want to fix a bug (and there ARE bugs, there will
ALWAYS be bugs), what do you do?
Of course, this is a temporality issue. FORTRAN's time has come
(or so I believe), C++'s will also. But there is a window of need, and
now we do need algorithms in the native language of the rest of the
Obviously, this does not preclude coding certain portions in other
language if there is undeniable gain (now and later), of using
code-generating techniques, but homogeneity of language is an help
towards the longevity of a given software, and the ease in making it
take advantage of new opportunities (multi-threaded MATLAB, anyone?).
> 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 code 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?
Boost allows *users* not 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
> diving in.
It is not that simple. Complex computations can benefit, in terms
of expressiveness and thus correction, of object orientation. Wrapping a
C or FORTRAN library wont cut it, in the vast majority of cases. Then
there is the issue of error detection, flow of calculation, etc..
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk