RE: [boost] Re: Boost Mathematicians

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>.

Reid

> -----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
> 
>    Bonjour
> 
> In article <c9m4td$alu$1_at_[hidden]>,
>  "David B. Held" <dheld_at_[hidden]> wrote:
> 
> > "Reid Sweatman" <drunkardswalk_at_[hidden]> wrote in message 
> > 
> news:!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAAQ16IR/xA0BGKJURFU1
> > 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 
> program.
> 
>       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 
> > 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: 
> http://lists.boost.org/mailman/listinfo.cgi/boost
>