A computer programming language sometimes claimed to be dead, mostly by people whose knowledge is decades out of date. See FortranLanguage
The Fortran 2003 standard has been approved. It contains many new features, such as ObjectOrientedProgramming
with single inheritance, IeeeSevenFiftyFour
arithmetic, and interoperability with CeeLanguage
, as described in the paper "The New Features of Fortran 2003" at http://www.kcl.ac.uk/kis/support/cit/fortran/john_reid_new_2003.pdf
About 10 compilers exist for the previous standard, Fortran 95, on both MicrosoftWindows
, with 4 compilers available for MacOsx
. There are links at the OpenDirectoryProject
A wiki with up-to-date information about modern Fortran is at http://fortranwiki.org/
It's not dead, it's just resting. See LessonsLearnedFromFortran for some valuable lessons doing Fortran not so long ago.
It's not even resting. See http://www.nag.co.uk/community.asp
for pointers to the large community using just one FORTRAN library, that of the NumericalAlgorithmsGroup
. -- KeithBraithwaite
It's not dead, it just smells funny.
It's not dead; it's pining for the fjords!
- 'E's not pinin'! 'E's passed on! This language is no more! He has ceased to be! 'E's expired and gone to meet 'is maker! 'E's a stiff! Bereft of life, 'e rests in peace! If you hadn't nailed 'im to the directory 'e'd be pushing up the daisies! 'Is metabolic processes are now 'istory! 'E's off the twig! 'E's kicked the bit-bucket, 'e's shuffled off 'is mortal coil, run down the curtain and joined the bleedin' choir invisibile!! THIS IS AN EX-LANGUAGE!!
FORTRAN is still very much the weapon of choice for people who want to do very big numerical computations, such as simulating atom bombs exploding, weather developing, planes flying, proteins folding and electronic orbitals, er, orbiting. It's not that it's a particularly great language (it's not - it's horrific), but there's a huge mass of very good subroutine libraries out there, and no other language has compilers which are as good at optimizing numerical code.
Shirley, you jest. This is the 21st Century, after all. "Numerical code" has less to do with compilers than with the expression of algorithms, so that argument is a RedHerring. FORTRAN is dead. Long live NumericalAnalysis through other means.
The array operations of Fortran 90 and later versions make it easy to express algorithms from LinearAlgebra
in Fortran - much more than so than in CeeLanguage
. [See also LinearAlgebraVsNumericalAnalysis
An algorithm will only get you so far... if you're working on large problems, on really large computers (say, a 512-node SP2), you still need the best compiler you can get, and aliasing concerns in C/C++ limit how much the compiler can do. Besides, dialects like HPF can get you farther with SIMD than C dialects I've seen, thus letting you get more out of those machines in less development time.
We don't know what language engineers will be coding in in the year 2100. However, we do know that it will be called FORTRAN.
I don't know what planet you're on, but on Earth (Sol 3, Western Spiral Arm) engineers use CeeLanguage if they have to, CeePlusPlus if they can, and whatever else happens to be lying around when those aren't available. Of course, I've only been doing electronics engineering for 25 years. Maybe you should ask somebody who's been around a little longer.
It's a joke, son - I say a joke. But maybe you should talk to some aeronautical engineers. There is a lot of important aero stuff which is still FORTRAN.
Holy Hand Grenade. Please tell me that in 2010 this is no longer true. If so, could you point to any examples?
Check your favorite search engine for Computational Fluid Dynamics at NASA, you will get a list of codes in heavy use at the space agency. Almost all were written in Fortran and most are still in active development in 2011.
- And for my part, let me remark that since 2003, William Kleb at NASA generates FORTRAN code from RubyLanguage, with testing, PairProgramming and all the latest agile fads.
There are not many good popular candidates to replace it in its niche. CeeLanguage
exposes too much pointer stuff, JavaLanguage
has intimidating libraries and library structures, and many engineering types probably don't want to deal with OOP. PascalLanguage
might be a candidate, but it is not different enough from FORTRAN to warrant a switch.
- Besides which, Java and Pascal (and most things one might think of) are not candidates, they suffers the alias problem almost as much as C, and hence cannot be fully optimized (e.g. automatic vectorization).
What about ObjectiveCaml?
What about it? What, did you just finish translating BLAS/LINPACK/LAPACK or something into OCaml?
No, but there is no need to translate when foreign function interfaces are available. See OCaml/GSL and PsiLab.
Speed is part of the reason that FortranLanguage
hasn't died (I presume you are implicitly referring to OCaml's speed), but is not the only reason. AplLanguage
has at times been known to do better than Fortran on various architectures, but that wasn't convincing enough. (BTW, no, PascalLanguage
was never a candidate, although at one time it made small headway there.)
Traditional numeric libraries are another important reason - necessary but still not quite sufficient. If all the classic numeric libraries become available, the next question is whether the competing language is perceived as being at least as simple as Fortran for non-programmers to learn.
I am under the impression that OCaml isn't perceived that way by anyone, least of all by Fortran scientific users, but correct me if I'm wrong there.
On the other hand I've been meaning to learn more about OCaml, so by all means start some advocacy pages. It doesn't seem to get nearly the hype that HaskellLanguage
I'm not sure FORTRAN is perceived as easy to learn so much as easy to teach when the only ProgrammingLanguage
that most of the staff in the physics department know is FORTRAN. My experience was that it was a pain to learn because of having to get things in the right columns etc., which was just hard to comprehend given that no PunchedCards
were involved. The development environment we were encouraged to use was a very basic TextEditor
and I can't really remember what the quality of diagnostics was from the compiler - but I don't think those helped either. Perhaps the biggest problem was that the courses were run by physicists who had little grasp of or interest in teaching good programming techniques - programs were just a tool to produce numerical results. Who cared if you would need a brain the size of a planet to maintain it? Once you had the numerical results, you threw the program away.
Actually your information about FORTRAN is quite out of date. Modern FortanLanguage? dialects, starting with Fortran 90, offer much more readable free-form syntax (no more punchcards), composite datatypes, modules, even OOP. And besides all the goods you get the compatibility with all these old, stable and much-tested-through-time code libraries. Obviously, Fortran is *not* the language of choice for writing WebBrowsers or sophisticated WordProcessors, but its portability across different computing platforms remains unbeaten nowadays. No-one will be willing to read numerical code bloated with #ifdef-s, nor with obscured quadruple pointer-to-pointer-to-array-of-functions-returning-indirect-pointers-alike relations. When was the last time you developed your CeeLanguage program on a PC and then successfully compiled it without modifications (and without bloating the source with #ifdefs) on 64-bit DEC Alpha (or Sun, or SP2 or whatever different from x86 architecture) and moreover got results, at least 30-40% within the results you obtained when running the PC version? -- HristoIliev?
The fortran referred to may be out of date, but the description of programming courses in physics departments is very much current (at least was in 2000-2002 in at least a couple of well-respected UK physics departments). The point being that these courses are run by physicists, not CS people, and the physicists only know old versions of fortran.
FORTRAN has strict rules on the order in which expressions are evaluated. For some numerical algorithms, this is very important.
I've been involved with electronics for some 40 years and learned some FORTRAN in the mid-1960s. I can't recall the last time I used FORTRAN. I tend to lump it in with that other bastion of early computerdom, CobolLanguage
, which I never did learn. If I need to do serious number crunching, I reach for my CeeLanguage
) compiler. While I won't say FORTRAN is dead, I would look in askance at anyone who thinks FORTRAN is the language to end all languages.
I've been working with FORTRAN (and still do on a month to month basis), Cee, CeePlusPlus
, IDL, Wave, etc. For data analysis, I find the RSI/IDL and PVWave languages have superseded my use of FORTRAN (shock-horror, even Excel comes in use), principally due to their interactive aspects. But for distributable applications, I've found FORTRAN is difficult to beat (the NAMELIST feature is fantastic for simplified parametric inputs that are readable and save so much time in rewriting new code for each new application) as it's quite consistent across platforms. Limitations I've found are lack of dynamic memory (addressed in later versions that I've been wicked in not learning, I'm limited to VAX Fortran extensions) and the string handling is difficult to interface with other languages (IDL, Cee, etc.) when creating shared libs/DLLs - but that could be considered (at least by myself) as a severe limitation of the encoding of character strings in these other languages (I mean null termination... what a wonderfully dangerous implementation, let's see a simple range check on that). My most favourite aspect of FORTRAN: it's not case sensitive - something whose necessity I've never heard a reasonable argument for... why would anyone in their right mind declare two variables "A" and "a" for use in the same routine?
No language is perfect at everything - Cee/CeePlusPlus
/Java/FORTRAN/etc - all have their strong points (although sometimes you have to be reminded when tearing your hair out). Perhaps we should consider them before the weak points.
I have to second the point about InteractiveDataLanguage (aka IDL) and its ilk (MatLab and other ArrayOrientedLanguage). I haven't written a numerical analysis program in FORTRAN in many years. -- GeoffSobering
Anyone know of free distribution of Fortran that can be used on WindowsOperatingSystems? Preferably one that can be linked to useful libraries, xml, gui, etc.
(MinGW) includes g77. (so does CygWin
, but cygwin is a whole 'nuther can of worms). given that fortran is usually used for pure numerics, I doubt using cygwin would be much of a performance hit. Still, mingw executables don't have the cygwin dll dependency, so one should use mingw first, and cygwin if one has to.
The free g95 compiler http://www.g95.org
is available for MicrosoftWindows
, and other platforms.
There's also the Watcom compilers, available at http://www.openwatcom.org/
This gives you both the hideous Cee/CeePlusPlus
and Fortran options.
It could be said that it has turned into a niche language (mass numerics) for which a significant challenger has yet to arrive. It used to be used for a wider variety of tasks. This is not unlike certain lines of animals that used to be prominent, but were mostly replaced by a more effective general design. However, they may have found a way to fit into very specific niches for which they still shine. For example, the Coelacanth is from an old linage of fish (that led to tetrapods). It appears to survive by having found a way to wind down its metabolism when needed to an almost floating hibernation. And "hag fish" (a pre-jawed fish) can produce gobs of slime that make it difficult for other animals to bite and catch. Both of these animals from "obsolete" branches don't have to be abundant eaters, the fastest, nor have high metabolisms; and instead found niches where laying in patient wait, and a few tricks, is the way to beat the odds and survive.
Fortran will never die as long as there are people who refuse to believe that 'code' is a mass noun. (That is, all "codes" are very often Fortran, whereas an indefinite mass of "code" can be any other language.)
These knocks on FORTRAN are superficial and fashion-based. "GOTO's don't kill programs, programmers kill programs". If only computer scientists could step back and actually innovate substantively in the ways we can program the same Intel chipsets, it would be refreshing. Ancient "debates" about programing styles, strong/weak typing, late/early binding and such are what's tired, not old languages like FORTRAN that still work perfectly well, and do things differently than modern languages. -AR
What are decent competitors in the field of efficient numeric computation?
- CeeLanguage is sometimes cited, but is arguably still not optimized for numerics.
- PythonLanguage, especially using NumPy? has mostly replaced it. All the MontyPython references at the beginning of the page prove it.