Fortran Is FORTRAN still relevant in modern programming?

[Astronuc]

I have experience with Fortran and C++. I'm most comfortable with Fortran, since it was the primary programming I learned since ~40 years ago. I guess any programming language that loses widespread support, or is not supported may be considered outdated. For me, learning C++ is a bit like learning Greek or Roman after growing up with one and being introduced by necessity to the other.

The big deal these days if object-oriented programming and where possible, parallel processing, as well as high performance computing and computational multi-physics. I have been involved in a program that selected C++ rather than Fortran because several issues mentioned by D H. Had there been a universally accepted standard version of Fortran, the program might have gone with Fortran. Various companies have tremendous quantities of legacy code written in Fortran, and some seemed compelled to stay with it for as long as possible. Programmers and computationalists will want to pay attention to INL's MOOSE system and it's suite (herd) of codes.

OpenFOAM is another platform of which to be aware.

The bottom line in computational physics/engineering is the ability to solve systems of coupled ODEs and PDE, which are often non-linear. There is also the time and spatial scales with which one must inevitably reckon. Therein lie many challenges in the near-term and long-term.Afterthought - I was first exposed to BASIC in 6th grade, then Fortran (66) during high school. During my first years of university, I took a course in programming which exposed me to Fortran, PLC and APL. Fortran seemed to be the most accepted coding system. In graduate school, I was exposed to Pascal with my first PC. Pascal reminded me of PLC. I've used Fortran most of my professional life, and only recently became involved with C++. I've known a few skilled programmers, and I'd have to say, Fortran is still useful, assuming one can find the right version and supporting compiler and hardware. I've heard of the benefits or advantages of C++, but I have not witnessed them in practice. Systems built on C++ still apparently need third party programs (TPP) to work, although I've seen that happen more frequently with Fortran and other scientific programming languages. It seems that inherently limits portability, which is another big issue in scientific program.

 

[Dale]

A tool may be both outdated and also still useful.

 

[bcrowell]

A tool may be both outdated and also still useful.

They still drive cars with tail-fins in Havana, but the reason isn't that those cars are just as good as modern ones.

Fortran survives because of backward-compatibility, not because it's the best tool for the job.

 

[jedishrfu]

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.

Okay I see it was due to a macro expansion problem. I'll keep that in mind. Thanks.

 

[bcrowell]

Okay I see it was due to a macro expansion problem. I'll keep that in mind. Thanks.

Yeah, the problem is that a lot of the standard language is implemented as macros, so the issue can crop up even if you don't write macros yourself.

 

[Dale]

They still drive cars with tail-fins in Havana, but the reason isn't that those cars are just as good as modern ones.

Fortran survives because of backward-compatibility, not because it's the best tool for the job.

I agree completely. My point was just that most of the posts supporting Fortran were arguing that it is still useful (because of backward-compatibility). In my mind that is a completely separate question from whether or not it is outdated.

IMO, Fortran is clearly and un-ambiguously outdated. Comments about its usefulness to me seem rather separate from the question.

 

[Aidyan]

All depends from what one needs. Fortran is powerful for high speed numerical computations, e.g. N-body simulations, eventually on platforms with parallel processors (in modern supercomputing it is widely used, along with C++) . It has the advantage to be easier than C++ and the code is clear and clean. While other languages died out, Fortran is still a good option for these reasons, and I believe it will not disappear for a long time to come. If however one has other aims, such as graphics or doing analytic calculus or needs a higher level language and is ready to sacrifice speed (e.g. what Mathematica or Matlab do, with the former however quite fast anyway), then Fortran is not a good choice. There are no universal rules. It all depends from what YOU are looking for. Most people stick to C++ nevertheless, but only because they have been taught to do so, not because of a logical reason. Lots of physicists will tell you that C++ is object oriented. But when asked if THEY have used object oriented programming for physics, usually the answer is negative. So, it is for most a habit, a learned skill from college, not a really pondered choice. If Fortran, contrary to so many other languages, survived the programming language selection of the last half century or so, there are very good reasons.

 

[mgkii]

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.

Lol :-) Oh yes we can. There's nothing unique in FORTRAN that can't be replicated in other languages.
Yours truly: Computer Science Major 25 years ago. One or two languages under belt since then (including FORTRAN of course!)

Serious point though - outdated in its dictionary sense doesn't imply "out-lived" in usefulness - we still use assembler and machine code in the bank I work for, and you can't get much more unfashionable than that! "Horses for Courses" as me old ma used to say...

 

[FactChecker]

Lol :-) Oh yes we can. There's nothing unique in FORTRAN that can't be replicated in other languages.
Yours truly: Computer Science Major 25 years ago. One or two languages under belt since then (including FORTRAN of course!)

If you say so. Be careful about flaunting your credentials to impress people that you don't know. I have done things similar to some of FORTRAN's namelist capabilities in interpreted languages that can 'eval' a string of code, but I have never seen anything that comes close in a compiled language. It would take a lot of tedious code to mimic FORTRAN's built-in, easy namelist. And the code would be specific to that one namelist.

 

[FactChecker]

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.

Ha! Another problem I have with new computers is that they finish a job so fast that I just know it aborted. So I start debugging. It's only after some time that I realize that it really did finish that fast.

 

[Dr Transport]

We still program in FORTRAN because we have not decided to allocate the appropriate budget to completely rewrite all of our codes. Now, with that in mind, all our new codes have been written in C++. Scares the living crap outta our new hires and interns when they have to look at FORTRAN.

 

[olivermsun]

Sometimes funding agencies are reluctant to grant budgets to completely rewrite things that already work, even if they are stylistically passé...

Also, your new hires sound like they just haven't been properly broken-in.

 

[rcgldr]

Whether or not Fortran is outdated depends on the program and the environment. A lot of stuff on scientific mainframes or supercomputers is still done in Fortran. There aren't many of the classic type of vector processor style supercomputers (Cray 1 in the 1970's, Cray Y-MP in the 1990's, IBM Virtual Vector Architecture, ... ) anymore, and even PC's have SIMD type instructions now. I'm not sure what languages are popular for the massively parallel type supercomputers.

Numerical weather prediction is one of the type of programs still written in Fortran. As far as I know there are no plans to change this. It would probably be easier to develop a new Fortran compiler for a new type system than it woudl be to convert the huge Fortran library (around 500,000 lines of code) for these type of programs.

http://en.wikipedia.org/wiki/Unified_Model

http://climatesight.org/2012/01/20/how-do-climate-models-work

 

[D H]

I'm not sure what languages are popular for the massively parallel type supercomputers.

The answer is C and C++. I'm toying with adapting hydro and SPH codes to use on a GPU. Nvidia's CUDA makes this easy. There are Fortan adaptations as well, but these are secondary add-ons. Optimizations for Fortran used to be primary; optimizations for other languages were the secondary add-ons. This is no longer the case.

The same goes for modern CPU architectures, which, underneath the hood, are becoming more and more Harvard-like and less and less Von Neumann-like as time goes on. Much of the interesting compiler development in this regard targets the C family of languages, with Fortran as a secondary afterthought.

 

[Khashishi]

Julia has a lot going for it, but the JIT compiling time is a major drag. Sure, it's very fast the second time you run it, but usually, you already got the answer the first time you ran it.
Perhaps, if it were possible to save compiled code as binaries and keep them between sessions, it would rule the world.

 

[mgkii]

If you say so. Be careful about flaunting your credentials to impress people that you don't know.

Flaunt and Impress! You've given me my daily smile just thinking about that... Your original post primed the grenade "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."

I am one (not much to flaunt there)... and we can (which isn't particularly impressive)

 

[D H]

I am one (not much to flaunt there)... and we can (which isn't particularly impressive)

My thoughts exactly.

For example, #include "some_checkpoint_restart_library_header" and then do a tiny bit of work to make your system checkpoint/restartable. There are dozens and dozens of checkpoint-restart / serialize-deserialize / marshal-unmarshal libraries, and for many languages. That this same basic concept has multiple names is indicative that Fortran is not the only language that has addressed this problem.

 

[FactChecker]

My thoughts exactly.

For example, #include "some_checkpoint_restart_library_header" and then do a tiny bit of work to make your system checkpoint/restartable. There are dozens and dozens of checkpoint-restart / serialize-deserialize / marshal-unmarshal libraries, and for many languages. That this same basic concept has multiple names is indicative that Fortran is not the only language that has addressed this problem.

I wouldn't consider FORTRAN namelists and checkpoints the same at all. I think you are underestimating the flexibility and ease of use of FORTRAN namelists.

Namelists are something a typical engineer can routinely use with confidence.

Some things to consider about namelist reads:
Variables not in a namelist are protected from being changed.
The syntax of the text file is not complicated.
A namelist read ignores other namelists in the text file .
The text file written by namelist writes can always be read by a namelist read of any namelist in the file.
The order of the variables in the text file is ignored.
All variables in the namelist do not have to be in the text file. The other variable values are not changed.
If an array name is in a namelist, individual elements of the array can be set in the text file.

In the programs I worked on, there are thousands of variables in dozens of namelists. And engineers use them all the time.

 

[wle]

I have done things similar to some of FORTRAN's namelist capabilities in interpreted languages that can 'eval' a string of code, but I have never seen anything that comes close in a compiled language. It would take a lot of tedious code to mimic FORTRAN's built-in, easy namelist. And the code would be specific to that one namelist.

I doubt you're going to impress the CS types with this. Lisp (maybe the archetypal CS language) has had compiled implementations going back to the 1960s and supports a first class symbol ("variable name") data type. You could certainly use this to implement something resembling Fortran's namelists.

 

[FactChecker]

I doubt you're going to impress the CS types with this. Lisp (maybe the archetypal CS language) has had compiled implementations going back to the 1960s and supports a first class symbol ("variable name") data type. You could certainly use this to implement something resembling Fortran's namelists.

Yes, Lisp has an 'eval' capability. I admit that I forgot about Lisp, but I suspect that most of today's CS majors are less familiar with Lisp than they are with FORTRAN.
I doubt that there is a two line example of Lisp code that will define a list of variables (all others protected) and read any subset of them in from a text file. It should have properties similar to those I mentioned in post #68 above. I also doubt that engineers and scientists would happily switch to Lisp from FORTRAN.

I didn't mean to insult CS majors, I just wanted to point out that there are things in FORTRAN that are useful to engineers and scientists but are not readily available in other popular languages today.

 

[SteamKing]

Yes, Lisp has an 'eval' capability. I admit that I forgot about Lisp, but I suspect that most of today's CS majors are less familiar with Lisp than they are with FORTRAN.
I doubt that there is a two line example of Lisp code that will define a list of variables (all others protected) and read any subset of them in from a text file. It should have properties similar to those I mentioned in post #68 above. I also doubt that engineers and scientists would happily switch to Lisp from FORTRAN.

There were some nifty applications which still used Lisp, but it's on the wane, too.

There was a symbolic algebra package called Derive which used something called muLisp, and it was surprisingly easy to use. Derive eventually got gobbled up by Texas Instruments and is no longer available as a stand-alone piece of software, but its symbolic algebra is used in some of TI's calculators.

The drafting package AutoCAD was originally written in Lisp, but I understand the core program was eventually re-written in C at some point. Because users could write routines in Lisp to add their own features to early versions of AutoCAD, the non-Lisp editions still had a Lisp interpreter built into the software to allow backward compatibility.

I didn't mean to insult CS majors, I just wanted to point out that there are things in FORTRAN that are useful to engineers and scientists but are not readily available in other popular languages today.

I wouldn't sweat it.

CS types have always been dissatisfied with any computer language which existed before last Tuesday. They've been trying to kill older languages like Fortran almost since they day they were introduced, and it must be galling to them that Fortran is not only still around, but it's been updated with a lot of their recommendations as to what features a "modern" language should have.

Of course, the newer Fortrans are a lot more bloated than say, Fortran 77, and it's becoming harder to write compilers capable of digesting all the new features and still generate reasonably efficient code, but it still bugs the CS types even more it seems that someone actually listened to them, and poured all that additional effort into extending the life of one of the first computer languages.

 

[wle]

Yes, Lisp has an 'eval' capability.

That's not what I meant. EVAL and similar functions will blindly evaluate arbitrary Lisp code. I understood that you meant something more specific and controlled.

I was pointing out that, roughly, variable names are a supported data type in Lisp that you can manipulate just like numbers or arrays. For example, you might have a variable var whose value is the symbol x. Then doing (set var 3) would set x (not var) to the value 3.

I doubt that there is a two line example of Lisp code that will define a list of variables (all others protected) and read any subset of them in from a text file. It should have properties similar to those I mentioned in post #68 above.

Well there isn't a two line example for Lisp for the same reason there isn't a two line example for sorting an array in Fortran: there doesn't happen to be a predefined function in the language that will do it. You could write one though.

Here's a simplified example that meets the most basic condition you asked for (a function that will read variable assignments from a file stream, and only assign the variables that are also in a user-supplied sequence), just to show it's possible:

(defun load-namelist (namelist &optional (stream *standard-input*)) 
  (dolist (assign-form (read stream))
    (destructuring-bind (var . val) assign-form
      (when (find var namelist)
        (set var val)))))

For example, suppose you have a file "vars.txt" with the contents

((b . 20)
 (c . 30))

You could use the function I defined above like this (example REPL session, return values omitted):

> (defparameter a 1)

> (defparameter b 2)

> (defparameter c 3)

> (format t "a = ~d; b = ~d; c = ~d~%" a b c)
a = 1; b = 2; c = 3

> (with-open-file (fs "vars.txt")
    (load-namelist #(a b) fs))

> (format t "a = ~d; b = ~d; c = ~d~%" a b c)
a = 1; b = 20; c = 3

This sets a few variables, runs the load-namelist function on a file, and prints the variable values both before and after processing the file. Notice that a retains its original value (because there isn't a new value for it in the file) and c also retains its original value (because it wasn't in the supplied vector #(a b)).

Of course, this could be refined to do more sophisticated things, like assign individual array elements and/or scan an input stream only for a specific, named, namelist, but you get the idea.

 

[FactChecker]

That's not what I meant. EVAL and similar functions will blindly evaluate arbitrary Lisp code. I understood that you meant something more specific and controlled.

I was pointing out that, roughly, variable names are a supported data type in Lisp that you can manipulate just like numbers or arrays. For example, you might have a variable var whose value is the symbol x. Then doing (set var 3) would set x (not var) to the value 3.

I didn;t know that about Lisp. I admit that is very powerful and would give you the desired capability. Even though it would take some work to make a namelist tool, that would be very possible.

Well there isn't a two line example for Lisp for the same reason there isn't a two line example for sorting an array in Fortran: there doesn't happen to be a predefined function in the language that will do it. You could write one though.

I agree. But one nice thing about FORTRAN was that they recognized that easy I/O to text files was so valuable for engineers and scientists. I consider namelist one of the best text I/O capabilities in any language.

Here's a simplified example that meets the most basic condition you asked for (a function that will read variable assignments from a file stream, and only assign the variables that are also in a user-supplied sequence), just to show it's possible:

(defun load-namelist (namelist &optional (stream *standard-input*))
  (dolist (assign-form (read stream))
    (destructuring-bind (var . val) assign-form
      (when (find var namelist)
        (set var val)))))

I stand corrected. That is very good. I like it a lot.

 

[gsal]

Well, this " Fortran, is it outdated? " thread certainly triggered a lot of replies...keep it up, guys, we don't want the " is Latex still relevant? " thread catch up

 

[Svein]

Since most of my programming has been in the "close to hardware" section (some people call it "system programming"), FORTRAN is not an option.

Somebody likes FORTRAN, though (see http://web.mit.edu/humor/Computers/real.programmers).

 

[nsaspook]

Since most of my programming has been in the "close to hardware" section (some people call it "system programming"), FORTRAN is not an option.

Somebody likes FORTRAN, though (see http://web.mit.edu/humor/Computers/real.programmers).

If you really wanted to you could (with the right hardware ). https://en.wikipedia.org/wiki/PRIMOS

An interesting feature of PRIMOS was that it, like UNIX, was largely written in a high level language (with callable assembly language library functions available). At first, this language was FORTRAN IV, which was an odd choice from a pure computer science standpoint: no pointers, no if-then-else, no native string type, etc. FORTRAN was, however, the language most known to engineers, and engineers were a big market for Prime in their early years.