Dismiss Notice
Join Physics Forums Today!
The friendliest, high quality science and math community on the planet! Everyone who loves science is here!

Fortran Fortran, is it outdated?

  1. Aug 17, 2015 #1
    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 im 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.
     
  2. jcsd
  3. Aug 17, 2015 #2
    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.).
     
  4. Aug 17, 2015 #3
    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.
     
  5. Aug 17, 2015 #4
    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.
     
  6. Aug 17, 2015 #5

    jedishrfu

    Staff: Mentor

    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:

     
  7. Aug 17, 2015 #6

    FactChecker

    User Avatar
    Science Advisor
    Gold Member
    2017 Award

    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.
     
  8. Aug 17, 2015 #7

    SteamKing

    User Avatar
    Staff Emeritus
    Science Advisor
    Homework Helper

    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." :wink:
     
  9. Aug 17, 2015 #8

    nsaspook

    User Avatar
    Science Advisor

    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 Harris 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.
     
  10. Aug 17, 2015 #9

    jedishrfu

    Staff: Mentor

    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.
     
  11. Aug 17, 2015 #10

    SteamKing

    User Avatar
    Staff Emeritus
    Science Advisor
    Homework Helper

    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 moreso 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.
     
  12. Aug 17, 2015 #11
    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? :biggrin:...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).
     
  13. Aug 17, 2015 #12

    SteamKing

    User Avatar
    Staff Emeritus
    Science Advisor
    Homework Helper

    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.
     
  14. Aug 18, 2015 #13

    Mark44

    Staff: Mentor

    Especially along about 1999 with the year 2000 looming on the horizon...
     
  15. Aug 18, 2015 #14

    SteamKing

    User Avatar
    Staff Emeritus
    Science Advisor
    Homework Helper

    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.
     
  16. Aug 18, 2015 #15

    jedishrfu

    Staff: Mentor

    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.
     
  17. Aug 18, 2015 #16

    FactChecker

    User Avatar
    Science Advisor
    Gold Member
    2017 Award

    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.
     
  18. Aug 18, 2015 #17

    jedishrfu

    Staff: Mentor

  19. Aug 18, 2015 #18
    Just from curiosity, I mean you can make it up- what would a big job entail?
     
  20. Aug 18, 2015 #19

    FactChecker

    User Avatar
    Science Advisor
    Gold Member
    2017 Award

    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.
     
  21. Aug 18, 2015 #20

    SteamKing

    User Avatar
    Staff Emeritus
    Science Advisor
    Homework Helper

    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.
     
  22. Aug 18, 2015 #21

    jedishrfu

    Staff: Mentor

    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.
     
  23. Aug 18, 2015 #22

    cgk

    User Avatar
    Science Advisor

    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.
     
  24. Aug 18, 2015 #23

    FactChecker

    User Avatar
    Science Advisor
    Gold Member
    2017 Award

    I brake for coffee breaks.
     
  25. Aug 18, 2015 #24

    SteamKing

    User Avatar
    Staff Emeritus
    Science Advisor
    Homework Helper

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

    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.

    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. :rolleyes:


    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. :wink:
     
  26. Aug 18, 2015 #25

    D H

    User Avatar
    Staff Emeritus
    Science Advisor

    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:
    Code (C):
    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 any one pointer in that function is restricted to that pointer alone. Those restrict-qualified functions generate code that is comparable to Fortran.


    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.
     
Share this great discussion with others via Reddit, Google+, Twitter, or Facebook