Is FORTRAN Still Kicking? 745
Algorithm wrangler queries: "I'm beginning to wonder if I should invest the time in learning FORTRAN. Although it is, arcane it seems to be the best tool when it comes to demanding optimization tasks and heavy computations. C/C++ does not cut it for me - it is simply too easy to make mistakes and I find myself using half of my time hunting bugs unrelated to the problem at hand. Additionally, although tools like Matlab exist they don't provide the power that justify the huge price tag they carry. I find any script based language (Matlab, Numeric Python, Scilab) to be inadequate as soon as it is necessary to use loops to describe a problem and using such tools for recursive systems can be a real pain. As another data-point, the Netlib repository seems to be very FORTRAN oriented, and it is a true gold mine when it comes to free routines for solving almost any computing task. What bothers me though is that FORTRAN code is really ugly and the language lacks almost any modern day language feature (I know about Fortran 90 but it is not much nicer than F77, and no one seems to use it). Can it really be true that the best tool we have for heavy duty computing is a 25 year old language, or have you found anything better - free or non-free?"
Don't complain about C! (Score:1, Interesting)
And it seems that C does all the things you describe (mainly that it's used in high-end commercial apps etc).
Of course FORTRAN may be just as reasonable a choice (I've never used it), but I'm just suggesting you dig a little deeper before throwing out C (and others) from your shortlist.
And finally, if you are doing some "heavy duty computing", you can completely rule out scripting languages.
FORTRAN is alive and well in HPC space (Score:5, Interesting)
Saddly, there's no GNU (or other Free) FORTRAN 90 compiler that competes well (or at all) with the commercial ones.
It all depends on the usage (Score:2, Interesting)
If you want something that is strongly typed and does recursion extremely well, I would recommend ML. Yeah its a bit funky if you've never used functional languages before, but its pretty damn powerful (I even wrote a compiler in it..) And its one of those languages that has almost been proved "safe".
I, myself, have never used FORTRAN. I guess I've never happened on an occasion to use it, so I'm not that familiar with its optimizations. However, gcc optimizations are pretty damn good at producing assembly that is just about as fast as someone hand-coding the assembly. Also, Intel has some optimized libraries (I know they have some for Image Processing...not sure about general math...) so that might be something to look into. And I"m sure its possible to rewrite the FORTRAN libs in C (or something that provides an extremely easy interface).
About to teach a numerical class... (Score:5, Interesting)
The course mainly focusses on solving machine numbers, solving linear systems (direct and iterative methods), solving non-linear systems (mostly Newton-type methods), and solving eigenvalue/vector problems. The codes that students wrote last year started from scratch with early assignments. Then, I allowed them to incorporate Basic Linear Algebra Subprograms [netlib.org] (BLAS) into their codes. Then they were allowed to use LAPACK [netlib.org] for the rest of the semester. They were free to use the C interface, but most chose to use the FORTRAN examples, probably because of the skeleton code that I provided.
Given the tremendous amount of code that is already out there, I agree that knowing FORTRAN is an asset. And since it's not hard to learn, why the heck not, right?
On a side note, they had to use Makefiles, LaTeX their assignments, and send everything to me electronically in a gzipped tarball. They got quite a workout in console tools. For reference, I had some that were quite familiar with the system and some that had had BASIC at some level and that's it. Lots of help was needed as the semester reached the final weeks.
Matlab was used for visualization and graph creation, but I am considering using GNUPlot this year, if it is up to the task. (I think it probably is.) I may also encourage the use of Octave [octave.org], where possible.
For reference, the class website (which will soon be updated for the new semester) is here: Math 224 [duke.edu].
Well, it's not a nice language, but... (Score:2, Interesting)
The language feels as though it's designed by a committee and has features tacked on left, right and centre. IO sucks arse, so don't expect to write a wonderful user interface for it (but you could always do a wrapper in another language, I suppose).
I use F90 at uni, and although it's a bit of a messy language it does what it's good at: spewing out tables of numbers. It is expensive for a single licence, however. I wouldn't bother with it if I didn't have access to the university number crunchers.
Err, big deal (Score:3, Interesting)
All we have is this "25 year old" language for numeric tasks, and another language that's about as old for system programming. It's called C.
Try SciPy (Score:3, Interesting)
Best of all, it's python, which means the learning curve isn't as punishing as C++, for instance.
The website for SciPy is:
http://www.scipy.org/
Re:Yes (Score:5, Interesting)
This is sort of true. Fortran isn't nessecarily all that much more inherently parallelizable than other languages, but because it is the language of scientific computing quite a bit of effort has been expended on compilers that automatically parallelize for vector computers. For non vector computers, it really doesn't matter what language you use - You'll be using MPI to do it anyway, so as long as you have a set of language bindings, you're ok. (Although as far as I can tell these only exist for C and Fortran...)
The real reason that FORTRAN continues to persist in scientific computing is twofold - First, there is a huge Fortran code base. Both in terms of things like Numerical Recipies and completed code. For example, I spent my summer integrating a Weather Model with a fluid dynamics model. The Weather Model, MM5 decends from the early 1970's (Pre FORTRAN 77). It's in Fortran. It's large. It would take a hell of a lot of effort to rewrite it, and nobody is going to do it. Theres a quite a bit of this stuff around, and the effort to rewrite it would enourmous, and frankly not worth it.
Second, most people programming in scientific computing are not CompSci's. They Computaional Chemists, and Electrical Engineers and Meteorologists and who knows what else - but not programmers. They learned FORTRAN and as long as they can get their stuff done in FORTRAN, they're not gonna learn C so they can track down a segfault when their pointers wander off an array. The new PhD's probably learned C and will use it if starting from scratch(After all, even in FORTRAN 90 Dynamic allocation and pointers are really, really limited, often requiring recompiles whne your problem size changes), but 40-50 year old computational chemists are not gonna learn C. Period. So FORTRAN continues to get upgraded. At least they got rid of the @#$% Hollerith-punch card column layout...
Say what you will about old languages... (Score:3, Interesting)
Also, despite what you say, well formatted Fortran code is no more ugly than most other code (and a hell of a lot nicer looking than your average Perl code :-().
I don't know why people believe that newer languages are automatically better. At the end of the day, you got storage, you got ops screwing around with the storage, and you got a mess of control flow holding the guts together. Just because I'm some hotshot wanting to get my name in the (geek-) papers with my shiny new syntax doesn't mean it's any different. And it certainly doesn't mean it's any better.
So go ahead and learn Fortran. Learn about the joys of representing linked lists as a set of next indices into an array. Learn about dimension statements and equivalence blocks. Learn how to squeeze down your numeric processing into the nub of a kernel of procedural truth. You'll end up being a better programmer.
Right Tool for the Job (Score:3, Interesting)
I've known FORTRAN since...well...for longer than many slashdot readers have been alive. Done big, numerically intensive projects in it for many years in the 1980s.
I've also done C (1990s) and C++ (2000s).
Ten years ago the criticism about speed was true - that compiled FORTRAN would beat C++ to pieces. Not anymore, unless you're committing newbie mistakes in C++.
If I were you I'd make the best of all worlds. I'd use Python for upper level logic in a clean syntax, in a quick scripting environment.
Then, if there's numerically intensive loops in the lower reaches of your code that get executed billions of times, go ahead and use FORTRAN. Especially when you're doing something like computing eigenvalues for specially shaped matrices, etc., where chances are someone has already written a FORTRAN subroutien to do it well.
Finally, use something like SIP or SWIG to connect the upper level Python to the lower level FORTRAN. Look, too, at Numerical Python and SciPy for others that have been down this road.
There's a lot to be gained from all those netlib routines that have withstood the test of time and been optimized to such an extent that even the FORTRAN programmers surrender, and drop down to call BLAS routines that are best written in assembler.
Using FORTRAN for the whole project is asking for pain once you start looking at things like parsing character input, connecting to network, linking into system libraries written in C. Been there, done that, have the scars.
Re:It's still kicking... (Score:3, Interesting)
While this may be true (although I think both C and FORTRAN are translated to an intermediate form), I'd say that gcc doesn't qualify as a high performance FORTRAN compiler. On the other side, if you look at the compilers provided with super-computers, the FORTRAN compiler is usually much faster than the C compiler. I heard the main reason is because of the C pointers. In fortran, when a function receives two arrays as input, the compiler can assume (it's part of the language) that they are different arrays. In C, for the same function, you are allowed to send it the same array twice (it's called aliasing), so because of that, the compiler is restricted in the optimizations it can perform. This kind of ambiguities happen in other places too. That being said, I HATE FORTRAN and for me, C++ when carefully coded can be nearly as fast (Of course, I'm also using gcc which performance is adequate but not more...).
Re:NOAA (Score:2, Interesting)
Not true, most atmospheric models have been written since 1980, although some of them were an extension of earlier models written in the 60s/70s. The earliest models were written in the mid-60s, and development on them didn't really take off until the mid-late 70s and early 80s, when models began to be introduced in rapid succession. Even today many models are currently being developed anew (the WRF and ARPS, for instance, neither of which existed prior to the 90s--in fact, the 1.0 release of the WRF was in Fall 2000), and new ones are announced quite frequently. They are still all written in FORTRAN, however, as FORTRAN is the standard for large-scale scientific computing.
Re:Bullshit (Score:3, Interesting)
It will be nice when the finaly do.
Re:Try Common Lisp (Score:5, Interesting)
it has a lot of good things that are similar to Fortran in the numerical world.
* Integers are not a fixed width, but transparently go to multiple precision instead of wrapping around.
* All of the intrinsics deal with complex numbers transparently.
* True rational numbers: i.e. ratios of integers.
* (Better than Fortran): STANDARDIZED parameters to describe the floating point parameters of the machine (e.g. machine epsilon). Also, built-in, portable access to the floating-point encoding in bit form. Very nice bit-bashing intrinsics (I like them better than C).
* Very flexible arrays. Some nice intrinsics (row-major-aref
* Notation is pretty flexible: can add multiple numbers together using (+ a b c d e f g).
* Lisp macros are amazing. The whole power of the Lisp language is available as a "preprocessor." You can relatively easily write programs that write programs that write programs. As an example, although Lisp has built-in, kick-ass OO (CLOS), you could write your own transparent object-oriented extension to Lisp (i.e., roughly equivalent to what cfront did for C) in about 200 lines of Lisp macros, and it works as well as if it were built-in.
Some slight "disadvantages"
* Prefix notation is the default. Add-on macro packages let you also write code that is infix
(e.g. #I instead (+ (expt a 2) (expt b 2) (expt c 2)))
but it is not a built-in standard.
* The standard does not *mandate* the ability to specify extremely large arrays. Not necessarily a real problem unless you want > 1 GB arrays on a typical 32-bit implementation.
* The notation is sort of verbose. Array references go like (aref array-variable i j k l). This is just notation, so the compiler should optimize this if you ask for it.
* Variables are not typed. The way around this is declarations. Again, the notation is somewhat verbose. (the double-float (+ (the double-float x) (the double-float y)) or (declare (double-float x y) (+ x y)). Again, this is just notation, so you can "easily" write lisp macros to write either of these as something like (d+ x y)
* Most high-performance computers have high-quality Fortran compilers. Fewer have high-quality architecture-specific Lisp compilers. Likewise for highly-multiprocessor machines.
* Most importantly, the bias in the Lisp world has been to optimize things like OO method calls, function calls, recursive function calls, automatic garbage collection. Not much pressure to optimize number-cruching on large arrays. Fortran compiler writers for the last 40 years have been asked to do one thing: optimize number-crunching on large arrays.
That said, for certain numerical codes, Lisp is a nicer tool than Fortran. For some other numerical codes, a good Lisp compiler (which might not be available for your architecture) given code with sufficient declarations could match a Fortran compiler for code speed, no more than 10% performance loss, sometimes performance gain. For some codes, Fortran is going to win big in execution time.
Survey Says: FORTRAN Most useful language (Score:2, Interesting)
I asked them to consider both the training (aka marketability) and educational aspects of their recommendation. I didn't want the concerns of getting a job to be the overwhelming focus of their recommendation. I wanted them to also think about how much useful experience, insights and language neutral knowledge they gained from the language they first learned.
Not suprisingly, BASIC was the most common language cited as "first learned" followed closely by PASCAL. FORTRAN, Modula II and SCHEME all placed in statistically close proximity to one another. Don't stop reading yet though- the punch line is to come.
A more interesting trend came from these same practicing programmers answer to the question of whether they felt their first language was of great help to them or simply a cross to bear. FORTRAN 77 was overwhelmingly cited as the most worthwhile language to learn from. This was almost universal among the FORTRAN first users and statistically relavent among those who'd taken learned other langauges first and come to FORTRAN later on. Please note this was conducted in '94 before FORTRAN 90 had sort of taken over.
The BASIC developers, once they had a bit of experience under their belt, as the source of many bad habits and of limited income earning and problem solving potential. The PASCAL initiates saw no use for the langauge beyond academia. Modula II was cited as a very educational language but with limited commercial potential. FORTRAN, though, was overwhelmingly cited as a great langauge to learn from.
It's simplicity gave the semantics a low learning curve but the richness of the constructs and the structure they impose avoided the bad habits picked up within BASIC. The respondents (other than the old hats) were also nearly universally suprised by how widespread FORTRAN was not only for legacy code but as an everyday prototyping and general purpose language. They found FORTRAN knowledge mapped easily into other imperative languages.
So, from both a practical, resume building point of view and for the holistic education FORTRAN will provide- go for it. 215 programmers can't be wrong.
vr/
Justin
Will Python take over FORTRAN's niche? (Score:5, Interesting)
It made me wonder if, with enough C extensions, Python can take over FORTRAN's niche as a high-performance heavy number-crunching language.
I don't know enough about the issues to make any predictions; I'm just wondering.
steveha
MATLAB & loops (Score:2, Interesting)
I do not consider MATLAB a replacement for FORTRAN, rather it's a fast-feedback analysis and visualization language. For matrix math it's unsurpassed. But I totally disagree about it being inept at looping--it would be a useless language if it were.
It's been years since I've used MATLAB extensively, but I remember writing simulation of electro-mechanical systems in MATLAB that used FOR looping, conditional looping, and breaking out of loops. No disrespect meant, but I suspect that the person who asked this question has only a cursory knowledge of MATLAB, the kind you get after having one linear algebra class in college where the most advanced operation you use MATLAB for is to find the eigenvalues of a matrix. If you're a EE, then you don't really get to see what MATLAB can do until you take some advanced control systems or power systems analysis classes.
For Numerical Fetishists (Score:2, Interesting)
Sure, you can get a math library for your favorite language that provides similar ability. You can get a regular expression library for other languages that gives you Perl-like abilities. But if you have ever used Perl, you know that the regex libraries of other languages cannot provide the flexibility-- the ease of expression-- the Awesome Power-- that Perl allows with regex. So it goes with numbers in FORTRAN. If you have a fetish for numbers, FORTRAN is for you.
Yea, FORTRAN code is write-only, like Perl... such is the price of expressive-control.
Old and well aged (Score:2, Interesting)
I have to personally give it a lot of respect since many Fortran compilers have a switch to toggle F66 syntax rules - as in 1966 - the year I was born! And Fortran was already 9 or 10 by that time.
What about R + dynamic linking? (Score:2, Interesting)
I am always shocked at how little attention R gets considering how good it is.
Re:Use Fortran 90 (Score:2, Interesting)