Is FORTRAN still relevant in modern programming?

[Tone L]

This summer I was a research student and my advisor used fortran (case 1). Two of my professors at my college use fortran (case 2). My friend at BU who is just starting his phd says fortran is huge and I should probably get a grasp on it (case 3).

On the opposite side of the spectrum, my computer science friends at college laugh at the fact of fortran... Someone in my lab during my summer research believed in the power of IDL which I mainly used, and python. I mean is fortran really that powerful? I mean people stick to what they know, and continue to use fortran but if I am proficient at python and for example people in my lab are all using fortran to solve problems I feel like i could easily solve the problems too using python.

 

[soarce]

FORTRAN stands for FORmula TRANslation, if you plan to do only scientific computation then FORTRAN may be a good choice: is in general faster than other compiled languages and because it has long history one can benefit from the long tested (stability, accuracy) numerical libraries.
For small problems I think it make no difference what programming language you use. For instance I used Matlab to do standard beam propagation simulation (two-spatial dimension + one-temporal dimension) and it took about two or three day to do a complete run,the duration of the simulation wasn't an issue. One will notice the difference when has to handle big problems (three dimensional simulations, fine grids) or when one needs to run very frequently the simulation and therefore it is better to rely on highly optimized programs and/or libraries which probably you wouldn't find it in Python but in Fortran or C/C++.

On the other hand, you plan to program other things besides scientific computations, for example graphical user interfaces, you will need also more flexible programming languages (C/C++, Java, Python, C# etc.).

 

[Fooality]

The thing about Fortran is that vast scientific and math libraries already exist for it, so it has that. I've never meet anyone with lots of experience with lots of different languages who actually prefers fortran though. Generally people learn to love the newer languages: Julia, Python, Haskell, Ruby, where you can accomplish the same things with half the code. But in terms of running speed and extensive existing libraries Fortran is impressive.

 

[gsal]

There are many reasons why Fortran is still around, besides those mentioned above, Fortran is easy to learn and easy to program in. You don't need a computer science degree to program a powerful, fast, optimal program in Fortran, that's why scientists and engineers typically continue to use it. Typically, writing the same program in C++ takes a much better programmer than a regular (non-CS) engineer.

If anything, the one reason why Fortran is loosing popularity is simply because it is not fashionable to teach it and, so, young people are not learning it.

Here is an interesting read: 1950's behemoth.

But yeah, if you are going to be doing GUIs, web, or database stuff, you don't need Fortran, that is not what Fortran is for...linear algebra? non-linear? huge data, huge vectors and matrices? high performance computing? Now you are talking Fortran's proven territory.

 

[jedishrfu]

Actually a good strategy would be to know numerical Python, Julia/Matlab and Fortran. There are many legacy systems that have at their core tested and approved fortran code and as extensions are made to the system people will use Python and its tested numerical libraries.

Matlab has become indispensable for engineering work and comes with a large base of software but as the code moves toward production then C/C++ programmers will often rewrite the algorithms. This is where Julia can shine as its syntax is very similar to Matlab but because it is designed around datatyping it can run orders of magnitude faster than Matlab at near C/C++ speeds. In addition, it can bind together Python, C and Fortran code together for legacy extension and at the same limit the need for a full code conversion to C/C++ as dictated when Matlab is used.

Checkout the Python / Julia Anaconda distribution with the Notebook IDE:

http://quant-econ.net/jl/getting_started.html

Also there are some YouTube videos by Dave Sanders showing the features of Julia using the anaconda distribution:

 

[FactChecker]

FORTRAN has some nice features for engineers and scientists that are not found in other languages. Namelist reads and writes are a good example. Computer science majors are usually not familiar with those things. Their first reaction is usually to think they can mimic it in other languages, but they can not.

 

[SteamKing]

FORTRAN has some nice features for engineers and scientists that are not found in other languages. Namelist reads and writes are a good example. Computer science majors are usually not familiar with those things. Their first reaction is usually to think they can mimic it in other languages, but they can not.

Computer sciency types have been down on FORTRAN going back to the 1960s, at least. I think the CS guys were chuffed initially because Fortran was developed by, you know, engineers and programmers at IBM, and not some of their CS brethren at a big research university. Even after a lot of the features that the CS guys say are indispensable to a modern programming language have been grafted onto Fortran, they're still not happy with it.

I also think Fortran gets a bad rap because a lot of people are introduced to it as their first or second programming language, and it takes a bit of getting used to thinking and writing in Fortran, especially with the newer, more complex language standard adopted for Fortran 90 and later versions. I still prefer Fortran 77, not least because I did a lot of programming in that version.

I started my program writing using a couple of different versions of BASIC which ran on HP 9830 and HP 9845 desktop "calculators", what would be called small computers now. The syntax of BASIC in general, and these HP versions in particular, was very similar to that of Fortran 66, so the transition to programming in Fortran for me was not as painful as if I had started without any prior experience.

A lot of programming languages have come and gone since the first Fortran program compiled back in the 1950s. This old saying is still true: "We don't know what language engineers will be coding in in the year _____ [fill in the blank]. However, we do know that it will be called FORTRAN."

 

[nsaspook]

One of my first programming jobs was using FORTRAN to read information from mag-tapes with data in standard 80 character Hollerith format blocks to 128 character blocks on single-density 8 inch floppies for some General Dynamics project contract. We had a then modern http://www.textfiles.com/bitsavers/pdf/harris/brochures/Harris_CPU_Brochure_Dec81.pdf H series machine so I could read the Buffered Block Channel from the tape, converted it to the needed format and sent it to the Communications Mux to a serial port on the external floppy with the needed commands to make it DOS compatible for some strange TRS-80 type machine they were using. To my surprise it was very easy to do record processing and communication I/O in FORTRAN if it was formatted as sequential data. Outdated or not it got the job done quickly then and I'm sure it still does with the right problems.

 

[jedishrfu]

When I first started programming in the early 1970's FORTRAN and COBOL where the primary choices with BASIC on the timesharing network. We used a variant of FORTRAN called Fortran-Y on Honeywell 6000 machines. One notable performance difference between FORTRAN and COBOL was that COBOL was more adept at processing data.

In general equivalent batch jobs, the COBOL job would cost about $10 company dollars vs the FORTRAN at $100 company dollars. The nearest I could figure was that COBOL did minimal data movement within memory and only converted data to numeric format when it was actually needed. In contrast, FORTRAN would convert all data read immediately into numeric format and/or copy it to some variable.

 

[SteamKing]

When I first started programming in the early 1970's FORTRAN and COBOL where the primary choices with BASIC on the timesharing network. We used a variant of FORTRAN called Fortran-Y on Honeywell 6000 machines. One notable performance difference between FORTRAN and COBOL was that COBOL was more adept at processing data.

In general equivalent batch jobs, the COBOL job would cost about $10 company dollars vs the FORTRAN at $100 company dollars. The nearest I could figure was that COBOL did minimal data movement within memory and only converted data to numeric format when it was actually needed. In contrast, FORTRAN would convert all data read immediately into numeric format and/or copy it to some variable.

IIRC, TS services had rate schedules for data storage and movement, as well as things like CPU cycles used during actual program execution.

COBOL may have handled large amounts of data, but the processing on the data was typically trivial: adding and subtracting more so than doing cycle-intensive work like extracting roots or evaluating trig or log functions like Fortran programs tended to do often.

If your Fortran program got caught in an endless loop because of a bug in the program or a flaw in the data, you could run up a TS tab to some serious coin in practically no time at all.

With some programs, the size of the data deck had little correlation to how many CPU cycles might be expended on a job. For some analyses, like finite elements and such, it might take weeks for the analyst to put together the data deck by hand and equally long for him to check the results after the job was submitted. Other programs might take more modest amounts of input data, but because the calculations were iterative in nature, it would take many CPU cycles to complete a job.

 

[gsal]

Interesting snippets of history.

In general equivalent batch jobs, the COBOL job would cost about $10 company dollars vs the FORTRAN at $100 company dollars.

Tell, jedishrfu, did you actually program the same exact thing in both languages and compare fair and square? Or was the Fortran program solving a huge 10000x10000 sparse matrix system of equations and COBOL solving for the change of Johnny buying a 75 cent candy and paying with a 1 dollar bill? ...just kidding...I know nothing about COBOL, other that it must be good at what it does as it probably suffers a similar fate as Fortran...most don't use it, but it continues to have its niche (within the finance/banking industry).

 

[SteamKing]

Interesting snippets of history.

Tell, jedishrfu, did you actually program the same exact thing in both languages and compare fair and square? Or was the Fortran program solving a huge 10000x10000 sparse matrix system of equations and COBOL solving for the change of Johnny buying a 75 cent candy and paying with a 1 dollar bill? ...just kidding...I know nothing about COBOL, other that it must be good at what it does as it probably suffers a similar fate as Fortran...most don't use it, but it continues to have its niche (within the finance/banking industry).

COBOL is one of those legacy languages that modern programmers hate, but there's a large installed base of code out there which would be prohibitively expensive to re-write in another language, so people keep using the old applications and pray they don't fail on their watch.

As a result, older COBOL programmers have retired, and there are a lot fewer young programmers coming up who want to learn to program in a decidedly different language. For a while, some IT head hunting outfits were offering premium salaries for anyone with COBOL coding experience on their resumes, to fill in the shortfall between low demand and an even lower supply of available talent.

 

[Mark44]

For a while, some IT head hunting outfits were offering premium salaries for anyone with COBOL coding experience on their resumes, to fill in the shortfall between low demand and an even lower supply of available talent.

Especially along about 1999 with the year 2000 looming on the horizon...

 

[SteamKing]

Especially along about 1999 with the year 2000 looming on the horizon...

Y2K was indeed a boomlet for IT employment, but since, every so often, some lucrative opportunities do present themselves to people occasionally who have the right skill set, not necessarily the latest skill set, though.

 

[jedishrfu]

Interesting snippets of history.
Tell, jedishrfu, did you actually program the same exact thing in both languages and compare fair and square? Or was the Fortran program solving a huge 10000x10000 sparse matrix system of equations and COBOL solving for the change of Johnny buying a 75 cent candy and paying with a 1 dollar bill? ...just kidding...I know nothing about COBOL, other that it must be good at what it does as it probably suffers a similar fate as Fortran...most don't use it, but it continues to have its niche (within the finance/banking industry).

Short answer is yes, it was part of a study to test the billing system used on our machine. I discovered that FORTRAN did a lot of convenience work for the programmer upfront by converting data for variables you weren't using but had listed in read/write statements whereas COBOL read data into a buffer (FORTRAN did too) but didn't move the data unless explicitly told to do so. In essence, COBOL was optimized to reference data directly from the buffer whereas FORTRAN was optimized for computation and performed data conversions upfront.

Why would a programmer choose FORTRAN to read large amounts of data from file and do very little computation? Because the program was easily a few lines long whereas the equivalent COBOL program was guaranteed to be 100 lines or more depending on the structure of your data.

 

[FactChecker]

This summer I was a research student and my advisor used fortran (case 1). Two of my professors at my college use fortran (case 2). My friend at BU who is just starting his phd says fortran is huge and I should probably get a grasp on it (case 3).I mean people stick to what they know, and continue to use fortran but if I am proficient at python and for example people in my lab are all using fortran to solve problems I feel like i could easily solve the problems too using python.

You should know from your experience whether FORTRAN worked well or not.
FORTRAN is significantly faster than Python, which may not matter on small jobs, but will matter on large jobs. There are also libraries for FORTRAN scientific subroutines that are documented better than anything else I have ever seen. See IBM Scientific Subroutine Package (SSP) at http://media.ibm1130.org/1130-106-ocr.pdf . But I don't know if there is a download for SSP.

 

[jedishrfu]

Don't forget the IMSL libraries:

https://en.wikipedia.org/wiki/IMSL_Numerical_Libraries

 

[Tone L]

You should know from your experience whether FORTRAN worked well or not.
FORTRAN is significantly faster than Python, which may not matter on small jobs, but will matter on large jobs. There are also libraries for FORTRAN scientific subroutines that are documented better than anything else I have ever seen. See IBM Scientific Subroutine Package (SSP) at http://media.ibm1130.org/1130-106-ocr.pdf . But I don't know if there is a download for SSP.

Just from curiosity, I mean you can make it up- what would a big job entail?

 

[FactChecker]

Just from curiosity, I mean you can make it up- what would a big job entail?

Python is interpreted and is several times slower at calculations that FORTRAN, C, C++ and the like. So "big" means that you get tired of waiting for it to complete the calculations. That could be in a single large calculation (large matrices, or other number crunching), or it could be repeated calls of many smaller calculations from a script. If you don't notice Python being slow, then it would be a nice language to stay with. But if you start a program that you will use a lot and then can take a coffee brake before it finishes, you should reconsider.

 

[SteamKing]

Python is interpreted and is several times slower at calculations that FORTRAN, C, C++ and the like. So "big" means that you get tired of waiting for it to complete the calculations. That could be in a single large calculation (large matrices, or other number crunching), or it could be repeated calls of many smaller calculations from a script. If you don't notice Python being slow, then it would be a nice language to stay with. But if you start a program that you will use a lot and then can take a coffee brake before it finishes, you should reconsider.

You step on the brakes to stop your car. You take coffee breaks while you're waiting for your program to finish.

That's one of the downsides to having fast computers everywhere now: you can't reasonably take a break from writing, debugging, testing, or running most programs, because they're done before you can turn around.

 

[jedishrfu]

The worst was when you thought you were done having just fixed that last bug and then after a long excruciating wait you find you still have something wrong.

 

[cgk]

I have many years of experience with both Fortran and lots of other languages across all categories. Compared to other compiled languages, Fortran is a ridiculously impotent language by modern standards; even some of the most basic features of other languages (say, complex data structures) cannot be relied upon to work (and certainly not to work well) across different compilers and platforms.

Interestingly, this seems to be both Fortran's main advantage and the main drawback at the same time: Yes, making complex, secure applications is very difficult, but on the other hand, in the scientific context this is often not strictly required, and since you are forced into very simple programming constructs, how exactly the program works can be much easier to understand for novices than in other languages. Additionally, this lack of raw power also makes it very difficult for an inexperienced programmer to royally mess up a big application. In a major Fortran program, you *can* let a graduate student with no programming experience make contributions without supervising every line committed. In C++, on the other hand, a single bad unsupervised programmer can raise havoc which can be neigh impossible to fix.

Some other comments:
- LAPACK is written in Fortran; this is the thing which keeps Fortran alive. It can be interfaced with C++, but this is not necessarily easy.
- The time in which Fortran code was faster than C++ code are long gone. With proper annotations (regarding restricted pointers and data alignment) and suitably structured code, there is literally zero difference in speed. (anyone who objects: try it).
- There are many large scientific and engineering applications which were started back in the time when Fortran was actually a good choice and outperformed old-style C. Some of those have several million lines of code and cannot be simply rewritten from scratch. This is another issue which keeps Fortran alive.

@OP: Should you actively learn Fortran? No. It can be picked up (literally) in one-five days (depending on the standard) if needed. Learning C++ would be much more useful. It is still a good idea to learn the Fortran-esque libraries (e.g., LAPACK/BLAS), because they are extremely important in other languages, too. You *never* want to roll your own dense linear algebra routines. It is universally a bad idea.

 

[FactChecker]

You step on the brakes to stop your car. You take coffee breaks while you're waiting for your program to finish.

I brake for coffee breaks.

 

[SteamKing]

I have many years of experience with both Fortran and lots of other languages across all categories. Compared to other compiled languages, Fortran is a ridiculously impotent language by modern standards; even some of the most basic features of other languages (say, complex data structures) cannot be relied upon to work (and certainly not to work well) across different compilers and platforms.

Fortran works well at what it was designed to do: Crunch Numbers, and lots of them.

- There are many large scientific and engineering applications which were started back in the time when Fortran was actually a good choice and outperformed old-style C. Some of those have several million lines of code and cannot be simply rewritten from scratch. This is another issue which keeps Fortran alive.

Not bad for a language which is "ridiculously impotent". There have been other languages which were designed to supplant Fortran, like Algol and even IBM's PL/1, but these replacements, and others, fell by the wayside for various reasons.

Interestingly, this seems to be both Fortran's main advantage and the main drawback at the same time: Yes, making complex, secure applications is very difficult, but on the other hand, in the scientific context this is often not strictly required, and since you are forced into very simple programming constructs, how exactly the program works can be much easier to understand for novices than in other languages. Additionally, this lack of raw power also makes it very difficult for an inexperienced programmer to royally mess up a big application. In a major Fortran program, you *can* let a graduate student with no programming experience make contributions without supervising every line committed. In C++, on the other hand, a single bad unsupervised programmer can raise havoc which can be neigh impossible to fix.

Fortran was never designed for systems work; no one would want to use Fortran to write an operating system or set up security for one.

It's like saying Joe Blow would be a bad football player because he spends all his time playing pro baseball. For a project I was involved with, I once resurrected a Fortran program which was written about 1960 or so. The original source for this program apparently had been stored on punch cards, and a listing was included with the documentation for the program. I had to type the program statements manually into the computer I was using at the time, and while I was doing so, I noticed that a call to a key subroutine was missing from the main program. Luckily, the subroutine source was complete, and I was able to re-construct the missing subroutine call and get the program running. One of the cards within the program source deck must have dropped out before the deck listing was printed.

In any event, computer languages are a lot like people languages: the more of them you know, the better off you'll be.

 

[D H]

Additionally, this lack of raw power also makes it very difficult for an inexperienced programmer to royally mess up a big application.

You sure about that? Fortran 95 added pointers to the language. There is a huge potential problem with pointers, which is aliasing. In C, this code is very bad:

array[0]=some_value;
memcpy (array+1, array, sizeof(array)-sizeof(array[0]));

On some computers, this nicely propagates some_value across the array. On others, you get a complete mess. memcpy is allowed to assume the two pointers do not alias one another. Pointer aliasing is your fault as a programmer for invoking this. The sister function, memmove is required to accommodate for pointer aliasing.

Fortran uses the memcpy rule, everywhere. It's always your fault if you invoke aliasing when you shouldn't have. This is a big part of why Fortran is (or was) so fast. "Was" because C added the restrict keyword in C99. This allows the programmer of a function to promise that memory through anyone pointer in that function is restricted to that pointer alone. Those restrict-qualified functions generate code that is comparable to Fortran.

Fortran is a ridiculously impotent language by modern standards; even some of the most basic features of other languages (say, complex data structures) cannot be relied upon to work (and certainly not to work well) across different compilers and platforms.

It's 2015, and there are modern Fortran compilers that are not yet Fortran 2003 compliant. From what I can tell, there is no such thing as a fully-compliant Fortran 2008 compiler.

 

[Fooality]

Python is interpreted and is several times slower at calculations that FORTRAN, C, C++ and the like. So "big" means that you get tired of waiting for it to complete the calculations. That could be in a single large calculation (large matrices, or other number crunching), or it could be repeated calls of many smaller calculations from a script. If you don't notice Python being slow, then it would be a nice language to stay with. But if you start a program that you will use a lot and then can take a coffee brake before it finishes, you should reconsider.

To be fair though it would be really unusual to use Python for matrices though, or anything like that. You would wrap some other library (maybe from Fortran) with Python. A pretty good example usage of Python in a serious setting like that is Google's very computationally intensive deep dream AI project: https://github.com/google/deepdream
Its based on C cuda code to run parallel on Nvidia GPUS for that teraflop performance, but the programming interface is through an Ipython notebook. So never forget the power of wrapping. If you're writing you're own algorithm though, yeah Python is about 600 times slower than C.

 

[jedishrfu]

One of the cards within the program source deck must have dropped out before the deck listing was printed.

More likely, there was a card jam and no one bothered to tell the programmer.

Even if you striped your deck with diagonal lines you'd likely not notice a missing card.

Such wonderful memories, the smell of punch card chaff, the pleasant sound of keypunch machines wafting in the air and the abject faces of programmers wishing they could just go home.

 

[SteamKing]

More likely, there was a card jam and no one bothered to tell the programmer.

Even if you striped your deck with diagonal lines you'd likely not notice a missing card.

Such wonderful memories, the smell of punch card chaff, the pleasant sound of keypunch machines wafting in the air and the abject faces of programmers wishing they could just go home.

Coding input on those special Fortran pads for the keypunch girl to use, the sound of a keypunch machine spitting out cards, carrying a large deck around in one of those card boxes which held 2000 cards (you got to know the weight of your data!), listening to the card reader on the TS terminal digest your deck and hoping it wouldn't jam ...

Man, I was glad when TS terminals got VDTs and would take electronic card images.

 

[Hornbein]

At some college I went to one of the professors programmed in FORTRAN. He had a poster of the Elephant Man on his office door with the text I Am A Man!

 

[SteamKing]

At some college I went to one of the professors programmed in FORTRAN. He had a poster of the Elephant Man on his office door with the text I Am A Man!

One of the early Fortran reference books I got was the Fortran Coloring Book:

https://www.amazon.com/dp/0262610264/?tag=pfamazon01-20

It was kitschy and outdated (it only covered Fortran 66, IIRC), but I still liked it for its unusual format.

 

[Dr. Courtney]

If you are a real physicist, sooner or later you are going to have to link to Fortran.

If you are a mere programmer, you can probably get by without it.

 

[jedishrfu]

... real physicist,...

... mere programmer...

Hmm

 

[D H]

If you are a real physicist, sooner or later you are going to have to link to Fortran.

Two comments:

• Linking to Fortran is easy. Just compile and link. There's a vast difference between linking to an old, outdated Fortran function and updating that old, outdated function.
• I guess that makes the people working at CERN just wannabe physicists. Back in 2003, CERN dropped its massive Fortran library in favor of the C++ ROOT package. I'm sure there are still a few legacy Fortran applications around, but the maintenance costs have pushed a lot of CERN to convert their software to C++, using ROOT.

 

[newjerseyrunner]

Yeah, your computer science friends in college are thinking in terms of general computer sciences. Fortran is pretty much useless for server applications, web applications, desktop applications... Your programming language knowledge is like a toolbox, a good engineer knows when to pick out what tools. Your computer science friends were just shown a hammer for the first time, they see how powerful it is, you can build pretty much anything with it.

Say you want to build a room / write a computer simulation.
An inexperienced construction worker / programmer will use the hammer / C++ for everything because it can do everything. It can hammer in the nail / set up memory structures and links and it can hammer in the screws / do the mathematical algorithm.

The experienced construction worker / programmer will use a screwdriver / fortran for putting in the screws / doing math, because experience has taught us that even though the general solution will work, the more specialized tool, makes a better end product and easier to change.

 

[Hepth]

Two comments:

• Linking to Fortran is easy. Just compile and link. There's a vast difference between linking to an old, outdated Fortran function and updating that old, outdated function.
• I guess that makes the people working at CERN just wannabe physicists. Back in 2003, CERN dropped its massive Fortran library in favor of the C++ ROOT package. I'm sure there are still a few legacy Fortran applications around, but the maintenance costs have pushed a lot of CERN to convert their software to C++, using ROOT.

We still use Fortran a lot from the Theory side, but its mainly due to historical use and having to interface with old code. We're still updating 15yr old Fortran code for some fits and integration routines because its faster for anyone who opens the code to learn Fortran than it would be for anyone to retype everything into C++. I really wish we would though. If I didn't have so much work to do I would rewrite it all.
Linking to it from Mathematica is a pain due to the wrappers.

Don't take the time to learn Fortran until you need to use it. Like mentioned earlier, if you're already a programmer, or a physicist who knows C/C++, Fortran is a breeze. It takes less than a few days to get the hang of it.