Is FORTRAN still relevant in modern programming?

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

 

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