Fortran 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.

 

[anorlunda]

I used FORTRAN for 20 years. I even contributed to the FORTRAN 77 standard. But in the 80s, I got UCSD Pascal on my Apple ][ and fell in love with it. I went from that to C to C++ to Visual Basic. VB was very productive, not because of the language but because of the development environment.

But in the process I became a FORTRAN hater. I hated the fact that 2/3 of all bugs were due to bugs in COMMON statements and abusive data overlay schemes in COMMON/EQUIVALENCE intended to save memory. I hated the fact that a typo like. DO 1 I=1 10 would compile without warning as DO1I = 110 rather than the intended DO 1 I=1,10 So many such bugs seemed unnecessary. I thought we should have machines that detect or prevent such bugs, not expensive engineers.

I tried to get my engineer friends to convert themselves from FORTRAN to C++, but I never convinced a single one of them. Once one learns a skill, one resists new things that deprecate the old skills. I remember one engineer in the early 90s who spent a whole year on a revision of his VAX program that saved 400 bytes. He was so proud of his memory shaving skills.

Thanks for reviving my memory of these things.

 

[SteamKing]

I used FORTRAN for 20 years. I even contributed to the FORTRAN 77 standard. But in the 80s, I got UCSD Pascal on my Apple ][ and fell in love with it. I went from that to C to C++ to Visual Basic. VB was very productive, not because of the language but because of the development environment.

But in the process I became a FORTRAN hater. I hated the fact that 2/3 of all bugs were due to bugs in COMMON statements and abusive data overlay schemes in COMMON/EQUIVALENCE intended to save memory. I hated the fact that a typo like. DO 1 I=1 10 would compile without warning as DO1I = 110 rather than the intended DO 1 I=1,10 So many such bugs seemed unnecessary. I thought we should have machines that detect or prevent such bugs, not expensive engineers.

I tried to get my engineer friends to convert themselves from FORTRAN to C++, but I never convinced a single one of them. Once one learns a skill, one resists new things that deprecate the old skills. I remember one engineer in the early 90s who spent a whole year on a revision of his VAX program that saved 400 bytes. He was so proud of his memory shaving skills.

Thanks for reviving my memory of these things.

Seems like you were blaming the language for buggy compilers or sloppy programming technique.

I too started programming on the Apple II with the UCSD Pascal system installed, and I even had the Fortran 77 companion compiler available on this system. It's amazing what you can cram into 48K when you have to. Some of the programs we wrote in Fortran would run all night on the Apple. When we finally retired the Apple and moved the software to an IBM PC, the same jobs ran in only seconds.

Apple Fortran was only a subset of the language, little better than Fortran 66, and it seemed like if you wanted to run a decent sized program on the Apple that one or more overlays were required because of the tiny memory available, but I never let the shortcomings of the implementation cloud my judgement of utility of the language, only this particular implementation. I knew that better compilers and computers with more memory were available; it was just a matter of acquiring these better pieces of software and some decent hardware on which to run them.

I wrote a few programs in Pascal, but it was a Meh language to me, not quite as cryptic as C, but not outstanding either.

 

[gsal]

I am an engineer (not a CS) and even I have had to learn a few programming languages, first Pascal...then Basic...then Think C... then Fortran77...then C++...then tcl...then Java...then Python...then Fortran90...but the bulk of the important code in my job has been a lot of inherited Fortran77.

And I would take Fortran77 over the likes C/C++...and I take Fortran90 even more so...Fortran90 is leaps and bounds ahead of Fortran77, and we have had it for 20 years now.

So, I do not find it valid when people say that they don't like Fortran because of a bunch of old features like GO-TOs, UPPERCASE code, EQUIVALENCE, COMMON blocks, code that must start in column 6, cryptic 6-letter variable names, fixed-size arrays, etc. Most of these features are deprecated or discourage (GO TO...but heck, a co-worker inspected the source of the Linux kernel and found that 1 in every 10 lines is a GO TO)

The fact is that Modern Fotran has some great features including modules, interfaces, generic interfaces, function/operator overloading, data encapsulation, type definitions, parametric type definitions, dynamic allocation, native complex type, pointers, to mention a few, but laslty its capabilities to handle arrays is amazing and very versatile. At the end, you end up with a very nice, clean looking code, unadorned with the likes of braces and semicolons or whatever.

But, hey, I am an engineer, not a systems programmer or a web developer...and, yes, Fortran90 is my favorite language along with Python.

 

[anorlunda]

Seems like you were blaming the language for buggy compilers or sloppy programming technique.

The DO example was not a compiler bug, it was a language feature of FORTRAN. Blanks were not syntactically significant except in Hollerith expressions, so "DO 1 I=1 10" was compressed to "DO1I=110" before further syntax processing by the compiler.

The sloppy technique with COMMON/EQUIVALENCE was forced upon us by the lack of heap storage, or any other facility for temporatry memory use. It led to bugs because of lack of INSERT or INCLUDE facilities in the language or the compilers. Declarations had to be manually replicated in each module. Even the editors of the day did not support copy/paste like facilities (which is not the language's fault). Every typo in those manually keyed duplicate declarations resulted in very hard to find bugs. And all during that time, all our software was restricted by the limited address spaces of the CPUs so smaller size outweighed readibility.

When I started, memory cost $1/bit and programmers cost $2/hour. Those harsh economics drove much of what came to be considered sloppy practices in later decades (including those infamous GOTOs) .

So, I do not find it valid when people say that they don't like Fortran

I didn't say I don't like today's FORTRAN, I said I didn't like it when I jumped ship on FORTRAN in the 1980s. But I should have made it clearer that I haven't followed FORTRAN's modernization since then. I'll take your word for it that it improved.

 

[ShayanJ]

Hmm

Don't be sad! I like programmers.

 

[cgk]

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

yes, it does---to some degree. But even in this area skilled programmers can much benefit from the more powerful languages. There is nothing you can do in Fortran which you cannot do in C++ too, if you know what you are doing. And there are many things in C++ which you would not even try in Fortran (I am not even talking about the expressivity of Python or Common LISP or similar).

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.

That is certainly inadvisable. But security does not end there. For example, even in a number crunching engineering application one might very well be interested in processing user input, and in doing this, not having a program which is not filled to the brim with exploitable stack and heap overflow errors. Almost all Fortran applications I have seen are simply horrible in this regard.

And, just for the record: I have actually seen interpreters for domain specific scripting languages written in Fortran 77/90. Which are widely used by 100s of research groups word wide...

Not bad for a language which is "ridiculously impotent".

Do not get me wrong: There is some extremely clever software written in Fortran. And I have the utmost respect for it. This includes, for example, the LAPACK, but also various other "legacy" scientific applications. I myself work on a program with about 2 million lines of Fortran and 250k lines C++ code, which is widely used in chemistry, and a lot of the Fortran code is very well engineered and very well thought out.

But just that such applications can be written in Fortran does not mean that it is necessarily a good idea for new programs. While a lot of this code is very clever, there are also countless instances of 2000-line-functions with 100s of if-then-else branches, copy-paste-slightly-modify code, functions taking 50+ function arguments etc., because a proper interface for these things can simply not be expressed in Fortran (for example, I have counted more than 10 slightly different versions of the same subspace convergence acceleration algorithm; in C++ I have only one of them). This creates serious maintenance problems.

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

This is not quite true in Fortran, because there is only so much you can do with the language. Many options you get with other languages are simply not there. Or they are formally there, but you can't use them because they are buggy across different compilers or outrightly unsupported (the last time I tried, in 2007, it was in practice impossible to put records in dynamic arrays or dynamic arrays in records, or do a number of other very basic things, because any of them would not work in at least one of the six different compilers the applications I had to work on was supposed to support. In 2007, compilers did not even fully the support Fortran 95 standard!).

You sure about that? Fortran 95 added pointers to the language. There is a huge potential problem with pointers, which is aliasing.

This is not quite as bad in Fortran, because the pointers are not as flexible as in C/C++. You can't make pointers to arbitrary objects (only to objects which are declared as "target"), and you cannot freely pass them around.

In practice, of course, you can get the aliasing problem entirely without formal "pointers". In many applications I have seen, the absence of dynamic memory management primitives made the scientists quite inventive: For example, commonly you see a big "work space" array allocated at the start of the program, which is then managed in a stack-like fashion. Memory is then allocated by taking off slices of this array, and passing around pointers into this array. This has a number of practical advantages in many applications, but you DO get all the "benefits" of pointer-arithmetic and aliasing related problems without having any pointer primitives at all.

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.

I agree. Basically, developers have more or less given up on Fortran, and there are very few compiler developers left. What we get in the end is a quite unreliable mass of "stuff", with all compilers supporting different subsets of the standards. So in practice one is more or less forced into the least common denominator: Fortran 90 and only the three basic types (doubles, integers, characters, and arrays of such). And maybe a flat structure from time to time---if you feel brave.

 

[D H]

I agree. Basically, developers have more or less given up on Fortran, and there are very few compiler developers left.

Compiler developer has always been an extremely niche job market. Nowadays, Fortran programmer is even more niche than is being a compiler developer, at least per indeed.com: http://www.indeed.com/jobtrends/fortran%2C+compiler.html .

What we get in the end is a quite unreliable mass of "stuff", with all compilers supporting different subsets of the standards. So in practice one is more or less forced into the least common denominator: Fortran 90 and only the three basic types (doubles, integers, characters, and arrays of such). And maybe a flat structure from time to time---if you feel brave.

Indeed.

I stopped programming in Fortran about the same time that I stopped programming in assembly. Needless to say, that was a long, long time ago. What I see nowadays is a few diehard Fortran programmers who insist their language is the best for their very narrow niche (despite growing evidence otherwise), plus a few diehard managers who insist their project will remain in Fortran as long as they're on the job (but they retire, or get promoted to managing an office of one).

Fortran had its place, but it is a dying language. Let it die in peace.

 

[jedishrfu]

FORTRAN is like Latin. Its not dying its simply out of fashion.

Someday it will have a resurgence on Kickstarter, "I guarantee it!"

 

[vanhees71]

Well, personally I use FORTRAN, because I'm used to it and too lazy to learn a new programming language, although I should, I guess. It also depends a bit what you want to do. Usually, for my personal programming purposes, FORTRAN is sufficient: I hack some not too long code for some numerical task I have to do, and usually it's fine.

I also often work with Mathematica, which is more intuitive and interactive (when it is used as a notebook), but usually more for help in analytical calculations. Sometimes also its numerics is fast enough, and I don't need to write FORTRAN code anymore for a numerical part of my work.

On the other hand, there are more modern programming paradigms like object orientation, which is very helpful for "big codes", i.e., codes which are programmed for multipurpose tasks (in my field it's relativistic transport in heavy-ion physics)and where many people work on the code. Particularly at universities, where you have many people like BSc/MSc, and PhD students, postdocs, who are working on some particular task using and extending a big code, it's very helpful to have an object-oriented setup and also well documented code.

Also one of the PhD students, I was co-advicing, used Python very efficiently, with the numerics parts partially written in C. So I guess, which programming language one uses, depends on what kind of problem you solve, what's most efficient given your programming habits/skills, and it should not be a kind of religion some people make out of it. This always reminds me of debates like "vi versus emacs" or "linux versus Windows" (although in the latter case, the answer is objectively obvious ;-)).

 

[Khashishi]

Different languages are better for different tasks. For the run-once analysis programs, something like Matlab, python, or IDL works quite well. For heavy duty numerical simulations that will run on supercomputers and take millions of CPU hours, it may be worth the extra effort to write it in Fortran. As for Fortran vs c, c is more structured and better for complicated stuff, but for pure equation crunching, you don't really need a lot of structure and Fortran works fine.

 

[bcrowell]

There is a problem in fortran because a lot of old code is stable, tested, and used every day for important tasks, and yet a lot of that old code was written in nonstandard dialects. There is starting to be a situation where you can't find a compiler that will compile that code. (Code written in old *standard* dialects can still be compiled.)

There was a language called Fortress that was supposed to play Luke Skywalker to Fortran's Obi Wan. Fortress died. Although I believe the cause of death recorded by the coroner was that their funding ran out, I get the impression that the underlying issue was an overambitious design that was not necessarily feasible to carry out.

Matlab is a proprietary language. Like all proprietary programming languages, it deserves to die. As with almost all such languages, there are good reasons to believe that it will.

Julia is a nonproprietary language that is clearly closely based on matlab. I tried it for a small project, and I got the impression that the implementation was amateurish. The start-up time is extremely long -- long enough to be noticeable by a human. I also immediately ran into a serious bug, which it turned out had been known for a year and a half but never fixed.

For a new project, I have a very hard time seeing the motivation for picking fortran. Efficiency and availability of libraries are not valid reasons. If you have a highly optimized linear algebra package or something that's in fortran, you can call it from a more modern language.

 

[Pantelis]

MATLAB rules..

 

[ChrisVer]

or "linux versus Windows" (although in the latter case, the answer is objectively obvious ;-)).

Obviously Windows...

 

[jedishrfu]

What was the Julia bug? I am curious to know if it finally got addressed. I was researching efforts needed to convert MATLAB to julia for performance.

 

[bcrowell]

What was the Julia bug? I am curious to know if it finally got addressed. I was researching efforts needed to convert MATLAB to julia for performance.

Inaccurate line numbers when syntax errors are reported: https://github.com/JuliaLang/julia/issues/1334

Re performance, julia is a JIT compiler. So it has terrible performance on a program that is expected to start up, do something, and then quit, but it may have good performance on something that is expected to run for a long time. There are some tricks for improving performance, such as IIRC not doing anything outside of a function.