Slashdot Mirror
Is FORTRAN Still Kicking?
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?"
As a recent CS grad I had to help some of my friends in the Meteorology department with their programming course(of course not taught by a CS prof). To my surprise it was FOTRAN. It seems a lot of the stuff NOAA and other government agenicies program is in FORTRAN so it is compatible with the stuff they stil use from the 70's and 80's.
"Success is not the result of spontaneous combustion. You must first set yourself on fire." -- Fred Shero
Fortran has several things going for it...
1) it's been the standard scientific computing language for so long, that every platform has a compiler, and that compiler is likely to be very mature (i.e. stable, and produces fast code).
2) since it's been a standard for so long, everyone has routines written in it which have been debugged and work, no sense rewriting them and introducing errors.
3) the language itself lacks complicated constructs, so it is very simple to optimize. This, with (1) makes fortran still outperform c, thanks to the compilers.
That said, I HATE fortran with a passion, mostly because it's ugly. 6 character variable names are impossible to deal with. Couple this with capitalization and indentation rules left over from the punch card era and you have code which is literally painful to read.
Doug
Venn ist das nurnstuck git und Slotermeyer? Ya! Beigerhund das oder die Flipperwaldt gersput!
The problems you described in C/C++ are probably mostly inherant to C. C is not type strict, so it lets you shoot yourself in the foot (or head) a lot.
What it sounds like you want is a strongly typed and type safe language. That would catch most of your problems, assuming your're just writing algorithms and not trying to interface to strange API or hardware.
PASCAL/MODULA-2/-3, or ADA can probably do what you want, and have GCC frontends available. These languages usually have runtime checks for safety, but after debugging, you can usually optomize them out for a production release.
So over all, go compiled, go type safe, go modern/OO if you can.
There is nothing so silly as other peoples traditions, and nothing so sacred as our own.
Fortran is used HEAVILY in very specialized industries -- almost any mechanical design or scientific modelling program has some Fortran code in it.
What do you want to do with it? Model fluid dynamics? Do structural or materials analysis? (Such software already exists.) Or do you simply want to find a better way to encode your DivX files?
It appears to me as though you are trying to select the proper tool for driving nails into wood, while looking in the screwdriver section of the hardware store. If you need to ask why you should learn Fortran, you probably shouldn't learn it.
- A.P.
"Remember when the U.S. had a drug problem, and then we declared a War On Drugs, and now you can't buy drugs anymore?"
I'm a big fan of Lisp... The ability to declare as much or as little as you want about your data types is very nice... And it has the greatest macros of any language I've ever used... Once you get used to the Lisp macro functionality, you will cry when the most you can do is a #define in C...
When programming in Fortran or C its important to remember Greenspun's Tenth Rule of Programming: "Any sufficient complicated C or Fortran program contains an ad-hoc, informally specified, bug-ridden, slow implementation of half of Common Lisp"
My Stuff: pspChess and foobar2000 plugins
You can use CORBA, or XML to communicate between your Fortran application, and any other code that you may write. That way, you can get the best of both worlds. I wouldn't give up so fast on C++/Java though. Investigate those languages more thoroughly before you decide to code in Fortran.
...of the simple loop structures. In C, you can have a for( ; ; ) statement that does basically all sorts of weird crap in here ( ; ; ), and you can also do things like pointer aliasing (impossible in Fortran since there are no pointers at all).
Fortran loops, on the other hand, are very very simple - all you can do is increment the loop variable, and repeat. That allows for very heavy loop optimization by the compiler - comparable to what the best assembly programmers might be able to do. Furthermore, a Fortran compiler can more easily generate optimized loop code using vector instruction sets like Altivec or SSE2, whereas C compilers have a much harder time (again, because of the wide variety of loop structures possible in C, and things like pointer aliasing, etc.)
All is Number -Pythagoras.
Having said that, when you're writing a large piece of code, much of the code probably isn't number crunching; its schlepping data back and forth between solvers, doing I/O, etc. For that, FORTRAN is fairly limited; so you use other languages.
You use the right tool for the part of the code you're writing. We are working on a large simulation code; our numerical solvers are all in FORTRAN, and we have no intention of chaning that; however, we use other things (C, Python) for higher-level tasks. And this is how it should be. People who argue about `Language X rocks!' or `Language Y sucks!' Just Dont Get It. All the languages still in use are still in use for a reason -- they have certain things they're good at. And so you pick the right tool for the job.
I see these annoying questions all the time. "Don't tell me that a 30 year old whatever is the best we have!" Alright, I won't tell you. But, I'll tell everyone else, Fortran is sometimes the best language for the job, even after 30 years. It is simple, fast as hell and very robust. What's wrong with that? Oh, you can't write a gui in it or you can't have derived object classes? Tough, that's not what it was designed for.
Why is it that the age of a language or tool is associated with it being inferior? Do you feel that everything that was created prior to your birth is inadequate or inferior? It is in fact, very common for the earliest versions of many things to be far superior to newer ones. This is true, not just for for languages but also for many other things. Most often, the "improvements" and "advances" that are made cheapen, dilute, complicate and destabilize the original product. This is, at least partly to blame for the disposable society that we live in today. Better, or smaller faster cheaper, usually also means less reliable and durable.
To answer your question, yes. Fortran is still a very viable language and is still, after 30+ years, the best language for heavy number crunching. If you need to create a gui and have derived oject classes as well, just link to the fortran libs. But, I'm sure that some snot nosed whippersnapper will suggest that Perl is the only solution. Puhleez!
While I certainly agree with your observation that Matlab is pricey, I don't understand your complaint that it is "inadequate as soon as it is necessary to use loops to describe a problem".
Heck, one of Matlab's greatest advantages is that every numeric variable is represented as a matrix and that many loops can be dispensed with completely with a little judicious linear algebra.
If you want to rip on Matlab, you'd be better off scorning its poor memory management or its byzantine handle graphics.
However, it does provide a nice development environment for computationally intensive problems. Scripting is a lot nicer than compile-link-debug-repeat when you're still trying to figure out the problem. Plus you can always farm out the most intensive processes to external code modules - which you can write in C/C++, Java or (gasp!) FORTRAN.
If price is the sticking point - why not take a look at GNU Octave. It is free as in beer (not GPL despite the name) and offers much of the same functionality as Matlab. Unfortunately, it shares most of the weaknesses of Matlab as well - and they are usually worse.
While the first two of the three points listed in the parent post are somewhat true, they are usually mitigated, depending on the languages you consider (e.g., you can find good compilers and well-optimized routines for C++ that will perform on par with FORTRAN, but maybe you can't for, say, Java).
However, the third point is actually a disadvantage in my mind: the overwhelming simplicity to FORTRAN leads to simple-minded implementations that are often less efficient (in time and especially in space) than a good implementation in a more modern language.
Case in point: Check out the sorting chapter of Numerical Recipes, and you'll find that their "ultimate" sorting algorithm -- and hence the algorithm that a whole generation of FORTRAN coders think is the fastest -- is heapsort. Now, heapsort is a fine algorithm, but it has some significant disadvantages over quicksort (the algorithm used in the C/C++ standard library. well, almost, anyway.) Of course, you can't implement quicksort properly in FORTRAN because the language isn't recursive! So, I guess it makes sense that they skip over it in Numerical Recipes.
These sorts of issues abound in FORTRAN programming. A lot of (older) engineers and scientists still insist that FORTRAN is the best language for high-performance mathematics, and to some extent, they're correct. As long as your mathematics are limited to those problems that can be solved with gobs of iteration, FORTRAN is your tool. But the minute you step into a realm where a more advanced data structure would be more important to performance (think hashes, heaps, trees, linked lists, etc. Places where algorithms actually matter.), FORTRAN falls flat on it's face. And don't even get started on space efficiency -- any modern language will beat FORTRAN 77 on this, hands down. Pre-allocation of arrays tends to kill an application's memory footprint...
Some of these issues are addressed in FORTRAN 90, but really, if you're going to use that language, you might as well use a language like C++, which is more common, and just as efficient, with proper care.
Let's try not to let fact interfere with our speculation here, OK?
In C++ I can extend the existing functions (such as sin(), exp(), operator+()) to support infinitesimals as well as ordinary floats or doubles. Using that I can automatically differentiate functions written in C++ making it trivial to code things like 2nd order optimisation routines. Try the same in FORTRAN. The nearest thing I can find anyone doing is using preprocessors that differentiate your source code line by line. (1) it's hideous and (2) well it's hardly still FORTRAN if you have to preprocess your code.
Using C++ it becomes trivial to write code to compute second derivatives in applications where the textbooks say things like "traditionally we make do with first order approximations because evaluation of second order computations are complex to implement". Of course they're hard to evaluate if your ideas of how to program come from the 1960s.
-- SIGFPE
There are some memory considerations and interface issues that make them want to switch over.
If it's mainly the interface issues, restructure the Fortran code as a library, factoring out the interface code, and then rewrite the interface in a different language. It's not that hard to call library functions from most languages.
Ooh, a sarcasm detector. Oh, that's a real useful invention.
i = 1
for j in xrange(1000): i = i + some_func(j)
Dumb example, but it more or less shows the issue... when you are dealing with data structures the overhead of the loop isn't that significant (e.g., doing list manipulation). But when you are dealing with numbers there's the potential to be much more efficient, and Python's for loop overhead will be very significant.
Of course Numeric Python can solve many of these problems, as can SciPy's weave and Pyrex, which compiles psuedo-Python to C. You can also program your inner loops directly in C, and make a Python module out of it. Or even write the module in Fortran.
Python clearly isn't a good language to write number crunching algorithms. But it's great for using those algorithms -- and it makes it possible (and relatively easy) to mix in other languages that are good for those algorithms.
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.
These are exactly the places where these languages excel, especially as compared with fortran! Fortran has only the most basic looping structures, and the lack of complex structures, pointers, and object abstraction makes writing any complex algorithm an excercise in mental anguish.
Things like Numerical Python were implemented specifically to put the control structures in a language that is readable, writable, portable and understandable. If you really need to, you can code the bit twiddling in C and link from Python/Matlab/whatever, but for god's sake, leave the high-level program structure up where you can read it.
"My opinions are my own, and I've got *lots* of them!"
PL/I, "the fatal disease", belongs more to the problem set than to the solution set.
The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offence.
APL is a mistake, carried through to perfection. It is the language of the future for programming techniques of the past: it creates a new generation of coding bums.
It is practically impossible to teach good programming style to students that have had prior exposure to BASIC; as potential programmers they are mentally mutilated beyond hope of regeneration.
Well, I think I might have heard somewhere that he actually said something nice about Algol, but I can't find a quote anywhere.
Anyway, I wouldn't bother too much about what Dijkstra said 10-20 years ago about programming languages long dead. Both FORTRAN, COBOL and PL/1 has clearly proven themselves useful in numerous real-world applications. And contemporary Basic, like Visual Basic shares almost nothing but the name with the kind of BASIC Dijkstra was talking about.
Of course, being a computer scientist, I certainly agree with him, but even I am not doing what I preach. C++ is certainly a large pile of shit, and C isn't much better. Java could almost make it, if it wasn't already so braindamaged by the C/C++ infection. Perl is certainly an offense to anyones aestethics (if people have that these days). Python could almost have made it if it weren't for the completely braindamaged scoping rules, and various other twarts.
Well, guess what languages I use at my workplace? Do I violently disagree? No, because these are the languages that actually do the job, they have fine implementations you can trust, they have lots of available libraries for almost any task, and most people already know them, meaning anyone can pick up where the last person left.
I am not a numeric analyst, so I've never had the use for Fortran, but if that was what I was mostly doing, I would certainly learn it. Learning to speak the lingua franca of numerical analysis will certainly be helpful if that's what you are going to do, even if you don't intend to use it yourself (but you will, trust me - I use C myself for the same reason). And I highly doubt that Fortran 9x is not much nicer than FORTRAN or Fortran 77, numerical people doesn't seem stupid to me, and certainly not as stupid that they would have invented it otherwise.
Keep your eyes on the progression of Python. They haven't fixed all the braindead scoping rules, but there appears to be an underground movement to move them towards something remotely more sane. Lots of work being done on Python between 2.0 and 2.2 . . .
A quick search on jobserve turns up 19 current job listings requiring Fortran. Not bad for a 30+ year old language. Several satellite, stress engineering and meteorology jobs.
Working code just doesn't stop working because some new language has come out. Imagine having the job of converting 5 million lines of fortran code into visual C++ dotNet code. By the end of the week. With no errors. And no overtime... It just doesn't happen, working code doesn't need to be replaced, and thus it isn't.
I'm still surprised when recruiters ask me about my fortran and cobol skills. I don't list them as skills, because I haven't touched them in more than a decade. But the skillPimps can see I'm an old fart, and the older ones know I started my career with the old languages, because perl and C++ didn't exist in 1972. Hell, Larry Wall was still in diapers when I first touched a computer.
This goes back to the discussion, here and other places, about the difference between coders and computer scientists. Coders insist the only language they know is the only one for the job, because they are too uneducated to understand a language is just a tool. CompSci gurus will just pick up the best tool for the job, whether something ancient like fortran, or something like a procedural language or even assembler.
the AC
Hemos is like...sci-fi fans;he thinks technology is cool, but he hasn't bothered to understand the science it's based on
(My apologies for the repost... wasn't logged in... argh!)
The performance difference between an optimal fortran program and an optimal C program I'd argue is nearly nil. Show me different, and explain why. Go on, try it.
Pointer aliasing.
The effort required to generate the "optimal" C/C++ program working with matrices or greater multidimensional arrays is nontrivially higher than the effort needed in FORTRAN.
Look, I'm not pro-FORTRAN. But credit where credit's due, people. C/C++ compilers worry about things that FORTRAN compilers don't, mostly because of the semantics of multidimensional arrays in each language (one should say the lack of multidimensional array semantics in C/C++). Why do you think Blitz is such a hit? Why do you think so many compilers have all sorts of non-standard ways of letting the user indicate that there's no aliasing on a given pointer in memory (remember noalias? what about those ugly restrict and unlikely_alias hacks?)?
You can make your number-crunching C/C++ code as fast as the FORTRAN folks' code, but it typically requires knowing more about your language tools than the aforementioned FORTRAN programmer worries about.
So, give them the nod on this one. You've got them beat on any number of other fronts.
Looking at ADA is painful. It looks like a language developed by a very large committee that wanted a language to do everything well. It acheives this, at the cost of being next to impossible to learn.
What do you think of C++, then? Almost every feature maps one to one between C++ and Ada, except for threading, which Ada has and C++ doesn't, and various knobs and dials on templates and object orientation (template specialization, multiple inheritance) which C++ has and Ada doesn't. Furthermore, Ada doesn't have redundant funtions, like struct and class, or multiple ways to cast a value.
Ada's not dead. There is considerable amount of embedded programming done in it, and some hobbist interest. Personally, I got tired of programming in a language where the first time I ran any program, its output consisted soley of "Segmentation fault". Most those programs, written in Ada, wouldn't pass the compiler; the other half would at least give me an exception with a line number for the problem.
Comment removed based on user account deletion