Fortran Language

A language for FORmula TRANslation. Some consider it dead, others wish it were dead. Some know that it is alive and well.

Invented by JohnBackus and his team at InternationalBusinessMachines roughly around 1956. It's one of the very earliest commercial high-level (cross-vendor) languages.

See DeadLanguageFortran, LessonsLearnedFromFortran.

See also: RationalFortran (RATFOR) = Fortran with block-structured syntax, like C.

But let's give it the respect it's due. Without the original, highly optimized compiler, programmers would not have bought on to the idea of using a HighLevelLanguage, and the development of programming languages would have been delayed.

MikeCowlishaw started out inventing his own programming languages while he was in sixth-form (17/18 years old) and wrote compilers for them in FORTRAN IV. The really scary thing is that FORTRAN IV didn't have strings!

The best approach was to extend the FORTRAN functional syntax and write SNOBOL pre-compilers to generate FORTRAN replacement code based on sub-routines and functions to implement the added functionality. This enabled, for example, graphic primitives to be included in FORTRAN programmes (and text processing). -- Geoff Stephenson

Scary? That was normal for a language in the early 60s. With FORTRAN IV, its job wasn't to process strings but to crunch numbers. It did it well and did it fast. As JohnMcCarthy said in his "History of LISP": "In the late 1950s, neat output and convenient input notation was not generally considered important. Programs to do the kind of input and output customary today [in 1978] wouldn't even fit in the memories available at that time." -- JoelRicker

But you don't need strings if you have character arrays - for example, what is a string in C but a character array with some library support? Somewhere boxed up I have an ancient parchment scroll (a book, actually) that describes just such text processing techniques in Fortran, and another book describing linked list techniques. -- an ancient anonymous coward.

I tried doing characters in FORTRAN IV in the late 1960's and never got it to work. Oddly my COBOL version needed only 2 or 3 runs to work. -- RichardBotting

People laugh at that, probably, without realizing that a large amount of money goes into writing the same damn things in C. There are even C++ libraries that emulate the Fortran way of handling linked lists, etc. Why? 'Cause it's fast.

Why on earth would people handle LinkedList in Fortran-style? (And what is this Fortran-style of linked lists anyhow?) Fortran may be great for numerical stuff, but I have seen some serious benchmarks which seem to indicate that you basically cannot beat ML [MlLanguage] when doing linked lists. Well, some good CommonLisp implementations might come close. -- StephanHouben

I needed to do some work with a lot of character data during the 1980's and did it all in Fortran. It was not easy but it worked. --JohnFletcher

ComplexNumbersAreYourFriends:

Fortran has complex number support that seems to elude every language since. Although both C++ and Smalltalk can define a complex type, neither can take full advantage of the processor's floating point unit.

PythonLanguage has built-in support for ComplexNumbers, but no implementations currently take advantage of any special complex number handling provided by the FPU.

Afaik, there are Python numerical packages that actually are wrappers around FORTRAN libraries that supply better matrix and complex number support - so then you can access that kind of functionality, but only thanks to the FORTRAN in the back.

Fortran's strength is its rigid structure. It does one thing really, really well: Matrix and vector calculations. The best mathematical algorithms in the world are written in Fortran. As a TA in college, I wish I had a nickel for every CS student that came into my classes deriding the algorithms because they weren't in CeePlusPlus, but couldn't program procedurally their way out of a paper bag.

Yes, and the fun starts when you want to integrate this code into your own applications. 20+ arguments, lots of "flag" parameters with functionality of the form: if n = 0, then wi holds the matrix to be inverted, if n = 1, wi is the current page number. Several "work arrays" with badly specified length. Code that is one big procedure, pages and pages and pages. -- StephanHouben

I use a lot of this "bad" code in my work. To StephanHouben's comment, I'd say you can find bad code in any language. But I'd even argue that much of the code that on first glance looks like the above description isn't bad. Yes, the interface may be clun,ky, but that's a result of various forces, only one of which is Fortran's (or more precisely pre-Fortran90's) limited set of data types and abstractions. For example, with a lot of numerical software, picking a single set of control parameters that will work in all applications simply isn't possible. You may not like having to specify four tolerance parameters, but you're the only one who can. And yes, code like you describe is hard to maintain, but it doesn't have to be maintained. It solves a well-defined, general problem, it's been beat on to the point where it works, it's been in its current form for 15 years, and it has no need to change. Look inside if you want to amuse yourself, but realize that for most of the numeric codes out there, you don't have to.

FORTRAN numeric libraries are fast; very fast. InTheory, C/C++ libraries could be just as fast, but in practice they aren't. (They haven't been pounded on hard enough by demanding applications.) So, wrap a good FORTRAN numeric library with C++ wrapper classes, and have some fun!

See, for example, LinearAlgebraPackage (LAPACK) which enables calculation of LinearAlgebra problems. The secret is that inside it there are core routines which are adapted for specific hardware (see BasicLinearAlgebraSubprograms or BLAS), interfaced through standard calls which provide the building blocks for more complicated algorithms. At the top level these can be built called from other languages. One of the values of this work is that it is done already, and as a result is often reused in different packages.

I'm not entirely sure that in theory C/C++ libraries could be as fast as Fortran. The reason is that Fortran disallows aliasing. If I have two vectors (say a and b) and make a modification to one (say a), in Fortran b won't change whereas in C it could. So Fortran code doesn't need to reload any values from b if only a has changed, which gives it a speed advantage. See GrokAliasing. The elegant solution is to do an AliasAnalysis. In fact, Fortran is no longer the fastest matrix computation language around. SingleAssignmentCee? and SisalLanguage? have beaten Fortran code in benchmarks. FunctionalProgrammingLanguages uber alles! ;-) -- NoelWelsh

Some C/C++ compilers can be flagged to assume (ie. optimize as if) there is no aliasing in the code. -- BrianCrowder

Doesn't C99's 'restrict' keyword help out with some, if not all of the aliasing problems? -- AnonymousGuy?

Sure, FunctionalProgrammingLanguages beat Fortran easily, especially if you take into account the time it takes to write the stupid algorithm. That's why I do my number crunching in ObjectiveCaml now. -- StephanHouben

I don't believe FunctionalProgrammingLanguages beat Fortran everywhere so easily. Fortran is great in some field, where other languages (maybe ObjectiveCaml) can be strong too. But this does not mean anything at all. Fortran(95) is good to do number crunching. In this moment, the only bad thing in Fortran pre-2003 is binary file I/O. -- MauroPanigada

EclipseIde can be used now for projects with FortranLanguage and for MixedLanguageProgramming.

CategoryProgrammingLanguage CategoryFortran