Is FORTRAN still relevant in modern programming?

[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 would 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.