From: Reid Sweatman (drunkardswalk_at_[hidden])
Date: 2004-06-15 17:13:23
Sorry to top-post, but I'm shot and in a hurry. Briefly, I thought I'd
implied all that. Wasn't suggesting anyone rewrite huge amounts of FORTRAN,
because very few people will. I wouldn't. Unless someone wanted to set me
up with a sinecure for life <g>.
> -----Original Message-----
> From: boost-bounces_at_[hidden]
> [mailto:boost-bounces_at_[hidden]] On Behalf Of Hubert Holin
> Sent: Tuesday, June 15, 2004 6:20 AM
> To: boost_at_[hidden]
> Subject: [boost] Re: Boost Mathematicians
> 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
> > QAAAKJAA
> > AQAAAArLDup9m3ck+fnQ8diyZEOwEAAAAA_at_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 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
> expenditure tomorrow.
> 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
> > it is much easier to separate the interface from the
> > 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.
> > Dave
> 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..
> Hubert Holin
> Unsubscribe & other changes:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk