Dead Language Fortran
Dead Language FortranA 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
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!
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 or CeePlusPlus. [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.
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.
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 does.
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 (not CeePlusPlus) 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.
MinimalistGnuForWindows (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, LinuxOs, MacOsx, 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
Competitors?
What are decent competitors in the field of efficient numeric computation?
See: LegacyStamp
EditText of this page
(last edited April 27, 2013)
or FindPage with title or text search