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?"
FORTRAN is dying
Yet another crippling bombshell hit the beleaguered *FORTRAN community when last month IDC confirmed that *FORTRAN accounts for less than a fraction of 1 percent of all servers. Coming on the heels of the latest Netcraft survey which plainly states that *FORTRAN has lost more market share, this news serves to reinforce what we've known all along. *FORTRAN is collapsing in complete disarray, as further exemplified by failing dead last [sysadminmag.com] in the recent Sys Admin comprehensive networking test.
You don't need to be a Kreskin [amdest.com] to predict *FORTRAN's future. The hand writing is on the wall: *FORTRAN faces a bleak future. In fact there won't be any future at all for *FORTRAN because *FORTRAN is dying. Things are looking very bad for *FORTRAN. As many of us are already aware, *FORTRAN continues to lose market share. Red ink flows like a river of blood. FreeFORTRAN is the most endangered of them all.
Let's keep to the facts and look at the numbers.
OpenFORTRAN leader Theo states that there are 7000 users of OpenFORTRAN. How many users of NetFORTRAN are there? Let's see. The number of OpenFORTRAN versus NetFORTRAN posts on Usenet is roughly in ratio of 5 to 1. Therefore there are about 7000/5 = 1400 NetFORTRAN users. FORTRAN/OS posts on Usenet are about half of the volume of NetFORTRAN posts. Therefore there are about 700 users of FORTRAN/OS. A recent article put FreeFORTRAN at about 80 percent of the *FORTRAN market. Therefore there are (7000+1400+700)*4 = 36400 FreeFORTRAN users. This is consistent with the number of FreeFORTRAN Usenet posts.
Due to the troubles of Walnut Creek, abysmal sales and so on, FreeFORTRAN went out of business and was taken over by FORTRANI who sell another troubled OS. Now FORTRANI is also dead, its corpse turned over to yet another charnel house.
All major surveys show that *FORTRAN has steadily declined in market share. *FORTRAN is very sick and its long term survival prospects are very dim. If *FORTRAN is to survive at all it will be among OS hobbyist dabblers. *FORTRAN continues to decay. Nothing short of a miracle could save it at this point in time. For all practical purposes, *FORTRAN is dead.
*FORTRAN is dying
How about sucky sucky my dicky?
I highly recommend it.
Just because I said "floating point" doesn't mean I use IEEE floating point formats. I'm using BCD. Not that it matters. You can most certainly keep all floting point noise below your precision, even when using IEEE floating point numbers. The problem comes up only when poor programmers who are unaware of rounding error perform iterative calculations without accomodating the imprecision. It is certainly NOT wrong to use floating point for financials. You just have to know what you are doing. In this sense, it is like all other programming. Ignorance makes errors.
If you wish to use only those programming tools which do not permit the programmer to produce an error, you will never write a line of code. Guess what? You can get it wrong using only integers. Perhaps we should do all calculation on paper with pencils? Wait, do you mean you can have errors there too? I guess we should simply never do arithmetic. We should just use random numbers. That will at least produce errors that are statistically equal on either side of correct. Yes, based on your view, that would be the best solution.
Grow up, get real (pun intended).
Some years back, at a university that will remain unnamed (so you might think it's yours ;-), a bunch of us grad students decided to instrument the Fortran compiler that was used for most of the number crunching on the big department monster machine. The hardware handled integer overflows by setting a flag bit, which then had to be tested by a separate opcode, and the Fortran compiler didn't generate this test. (For floating point, there was an interrupt that couldn't be ignored.)
The instrumentation added a test that recorded the overflow, let the computation continue, and wrote some results to an accounting file.
What was found was that almost exactly half the Fortran runs produced at least one output number that was wrong due to an undetected overflow.
When this was publicised, a survey of Fortran users was done. They were asked whether the compiler should test for overflow if such a test would take an extra opcode and slow the program down. around 90% of the users said that such tests should not be done if the program would run slower.
This taught us an important lesson about the Fortran user community. And note that in the replies here, a lot is made of Fortran's optimizations. Now you know what that means.
Around the same time, there was one of several analyses of the Fortran runtime libraries on IBM 370 mainframes, which are still in wide use for big number-crunching applications. The analysis showed that the double routines were accurate to only float precision over roughly half the range of their arguments. At the time, these routines had been in widespread use for maybe two decades.
When a Fortran programmer uses double rather than float, it usually means that the computations needs the extra precision, and float doesn't have good enough precision to give correct output. For users to accept a Fortran that can't do doubles correctly half the time is another good sign of the nature of this user community.
So in general, Fortran users seem to use it because they consider efficiency more important than correct results.
I wonder if Enron's accountants use Fortran?
Those who do study history are doomed to stand helplessly by while everyone else repeats it.
IDL's graphics drawing routines are subpar, performance-wise. Don't use it if you need to optimize for speed...
It's also has a weird and clunky GUI toolkit. It's great for slapping something together quickly for analyzing and manipulating stuff, but I have reservations about using it as a general purpose tool.
WE ARE NOT TALKING ABOUT PCs YOU FUCKWIT
CPU time on really big iron is charged for, time is money.
Quick and dirty - that's true.. All fucking astrophysics community is hooked. Expensive habit..