somewhere in the E.U., le 15/06/2004 Bonjour In article <c9nc0o$7d5$1@sea.gmane.org>, Deane Yang <deane_yang@yahoo.com> wrote:
Thorsten Ottosen wrote:
"Reid Sweatman" <drunkardswalk@earthlink.net> wrote in message news:!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAAQ16IR/xA0BGKJURFU1QAAAKJ AAAQAAAArLDup9m3ck+fnQ8diyZEOwEAAAAA@earthlink.net...
| Oddly enough, scientists is usually pretty | conservative folk; they like what they know.
Is that so odd? Yesterday I talked with a matematician here in Sydney about Fortran. He uses Fortran because it is good enough for what he is doing. It would probably take quite some time for him to learn C++, so why should he?
Agreed. It's the newcomers that we want to snare, before they've been indoctrinated into Fortran. New mathematicians tend to have at least some computer science training, so they will be looking for more than Fortran to write their code in. The competition will in fact be in the other direction, from languages like Ocaml.
Why would he want to learn C++ to do his computations? What about better expressivity? If you need complex numbers, you want to treat them as full-blown critters, and (most frequently, if not always) not as simply a couple of reals. You want to write a+b and x*z, and that the various components work correctly. If your favorite plaything is even weirder, you definitely want to consider it as an object. One thing should be kept in mind: a great many tasks which require to too trivial math either will be carried out with ***prototyping*** software such as MATLAB or SciLab, or made into a custom software which will only be run a few times. In that case, rapid deployment is essential. In that case the object approach (including its C++ incarnation) shine. One would of course want that once the prototyping is done, minimal effort would be involved to put into place a frequently-run, or expensive-run (a.k.a. Cray-like "supercomputer" using) software. But for one such software, how many smaller ones have been made (just to test an idea)? Furthermore, Massive Mainframe Mastodons may perhaps not really represent the future of supercomputing (think "cluster", and distributed computing is a can of worms in and of itself). Waste is bad, but being too clever for one's sake can also not be too good (just consider the original Mac's handling of memory: it was designed to have large programs run with tiny physical memory available, it was brilliant, it was a reason why developers hated working on that platform...). So perhaps not having the best-possible-ever optimization will appear increasingly less significant. So the perceived efficiency edge of FORTRAN will, IMHO, prove increasingly irrelevant. So why not learn C++, which will *also* help with other programing tasks (GUI, etc.)? There are other reasons, such as error handling, and the flow of computing which must be adapted to it. I would favor (and this is the approach I took with the libraries I submitted) an exception-based flow, as it seems (to me at least) more natural that what FORTRAN, C and others currently have. Hubert Holin