Invitation to all readers: please comment on why you still use Fortran

[FortranFan]

Hello Everyone,

Would you be kind enough to comment as to why you still use Fortran in present day and age?  I'll be especially interested in reading responses from those of you who a) program on Microsoft Windows OS (Windows XP/7/8, Windows Server 2003/2008, etc.) and b) are in a non-academic environment - industry (IT, engineering, manufacturing, etc.), research/technological institutions, national/international labs and agencies, and so on.

Chances are that almost any programming we all do can also be written in a host of other computer  languages.  And on Windows OS, one may be able to do so in very rich integrated development environments (IDEs) with a lot of user-friendly features such as Intellisense to further enhance productivity and ease-of-use.  One only needs to look at Microsoft Visual Studio with native (C/C++) and managed memory (C++, C#, Visual Basic, F#, etc.) options with extensive libraries and packaged solutions like MFC classes, .NET framework, etc.  Not to forget solutions for Microsoft Excel (isn't it the largest number-crunching/simulation environment, at least in terms of number of people!) in the form of VBA and Visual Studio Tools for Office (VSTO).  And there are so many other offerings from so many vendors other than Microsoft.

So why continue to use Fortran?

It is easy to understand why Fortran will be preferred by those involved in truly high-performance computing (HPC), say on Cray supercomputers at a national lab such as Sandia.  Co-arrays and other parallel processing features in Modern Fortran may prove highly valuable in HPC.  But I assume this is only a small fraction of the user base?  What about the rest of us? 

At the organization where I work, I've to coordinate a "round-table" discussion soon with some high-level folks on the role of Fortran in our computing environment.  Hence my interest in understanding why Fortran continues to get used in the face of so many other choices.

It'll be great if you can try to compose your comments in the form of "I program in Fortran because .." and simply state your reasons.  This may help you steer you away from indulging in criticism of one or any of the other options.  Note I'm NOT trying to create a "Fortran vs ..." battle.  And it will be good to move beyond stock responses based on perceived advantages of Fortran in numerical calculations and array processing on ordinary computers: many experts have discussed this extensively - not to forget modern editions of "Numerical Recipes in .." by Press et al. where they have moved beyond Fortran.

Note I use Fortran extensively, especially for scientific programming.  And I'm quite excited about modern Fortran.  Hence please do not view this as a "dig" on Fortran in any way.  I am simply trying to collect useful "talking points" for the discussion in my organization.  I'll post my own rationale later on when the responses start slowing down.  I would like to read your views first.

Thank you in advance.  Sincerely,

[DavidWhite]

Here are my reasons:

1. High level of optimisation and computational speed.

2. Many mathematical methods already coded and optimised and available in the public domain, and so can be used in proprietary code.

3. Integration with other applications, high level process simulators, which use Fortran for user-based models internally, OR can integrate externally with user-developed executable code.

4. Code much more readable than some variants of C/C++

5. I've been using it for more than 35 years, and so I'm more efficient and developing and debugging Fortran code than I am in using other languages.

Regards,

David

[michael_green]

I use Fortran because:

Fortran has been used in my organisation since the late 1970s and I have been using it since 1985.

We still have some legacy code around written in FORTRAN IV. It's disgusting to read, but it works - why change it?

Well written modern Fortran is easy to read. Parts of it can be used like pseudo-code which non-programmers can readily understand.

Whilst learning Fortran and C/C++ for Windows over the last 10 years, I have had better and more enthusiastic support from the Fortran crowd (this forum) than from the C community.

Cheers

Mike.

[Anthony_Richards]

I was taught Fortran IV as an undergraduate over 40 years ago. It is ideal for computing using scientific formula and I became pretty proficient in its use. I moved into solar/space/research environment and I found Fortran ideal for what I wanted to do. I was not interested in learning other languages (PL1, anyone?). Computing was still dominated by batch execution, where you had to wrap your code with job-control language cards (a real pain to learn) and then send it to the mainframe computer and then wait for the dreaded abort print-out.

The main shortcoming I found early on was the great difficulty in linking Fortran data produced on a mainframe computer to plotting devices so that you could quickly view results pictorially. This was a continuing gripe (mitigated somewhat when I got my first PC, which had a screen that was crying out for me to program squiggles on it!). Even the old BBCcomputer/Sinclair Spectrum forerunners using Basic could plot stuff easy than a minframe in those days. MS Fortran Powerstation was the first compiler I used on a PC.

When I graduated from PC to workstation (more memory, faster processor etc.), I was delighted to discover MathCad and I eventually developed skill in using MathCad, which I find excellent for testing algorithms and viewing/plotting data, before writing production code in Fortran. Many colleagues use IDL instead for all its graphic and image processing capability, although having tasted it myself, I still prefer to do my production (as opposed to development and testing) number crunching in Fortran as its code is always much faster than MathCad. I note that many Fortran program programmers mourn the loss of the Array Visualiser for rapid examination of data during development. Although I never used it myself, I can see why the loss of such a resource is a backward step and I hope that there are moves to reinstate it in future.

Of necessity, I have explored C++, because of the need to understand MS Windows API when developing using Visual Fortran (in Digital,Compaq and Intel versions) . I have an instinctive dislike of C and C++ because of its finicky (and somewhat ill-explained) dependence on, and failure in the absence of, correct punctuation with semi-colons and open and closing brackets etc. and so I will never learn to like it (especially at my age!). However, the swiftness with which Visual C++ and its sister language environments enable you to make up GUI for your program I much admire. The way that  starter code is automatically added for each control that is added to a form I find attractive. However, I find I can easily 'read' fortran code whereas C++ code I find largely unreadable (most probably because of the imbalance in my experience of the two languages).

I have also learned Visual Basic for Access when made responsible for maintaing a Health& Safety database as a side line from my scientific/design work, and the ease of coding in controls, handling objects (including database objects) makes me pine for similar easy-to-use capability in Fortran.

I echo the comments of those posters above, especially the comment from Michael about the programming assistance one can get here. I note though, that whenever I had a VBA programming query, typing in the gist as a Google query usually turned up a solution or assistance from somewhere on the web.

I guess I should now get back to work and Spider Solitaire.

[TimP]

Your question implies an interest in writing Windows-centric applications and that Fortran is unsuitable for producing managed or unmanaged code to work with .net.  The other side of this is the question of how desirable is choice of tools which promote non-portabiltiy and breakage with each major version of Windows.   If those dialects of Fortran which worked only with managed code didn't catch on, is that a strike against Fortran or one against proprietary limitations?

The continued usefulness of Fortran "even under Windows" is demonstrated by the continuing popularity of multiple excellent commercial and free software implementations, as well as Windows capabilities in thrid party libraries.  You might note the way in which the interest in Fortran has promoted updates in gcc/g++ as well as gfortran for Windows, if you think Fortran is an isolated arena.  Not to mention that iso_c_binding corrected an important part of the Microsoft vs. rest of world interfacing incompatibility over 5 years ago.

Fortran has gained renewed interest due to the facility of use by those who don't have time to become computing specialists.  Note the parallel computing course prerequisiites at U Texas Austin where Fortran is accepted on an equal basis with others.

[Les_Neilson]

At Uni I used Algol60. When I started working I used COBOL and a little bit of Assembler on a mainframe. Then I used Fortran on mainframe,  mini, and PCs for about 35 years. I also used some C, more C++ and now I have to use C# (In the company I now work for I do not have access to a Fortran compiler :-( ) Of all the languages I like Fortran the best. I have used it for modelling processes (something like Multiple Activity Charts), CAD, geology, surveying, mapping, contouring, steelwork design, environmental modelling and probably other things I have forgotten.
It is the language I am most familiar with and so find coding very easy to write and read (especially compared with say the C/C++/C# area.) This is very important when it comes to maintaining code written by other people. I have fixed bugs in Fortran code written by other people quicker than those in C++/C# code written by others or myself!

Les

[Said_E_]

The question about the usefulness of Fortran in business is quite understandable, specially if you think about the Windows-based database systems now available in the market. It eases the creation of tables and forms while maintaining the integrity if data and enabling the querying of database contents. What is more understanding is that you can still call an own code from the database to process a desired function or subroutine. This argument started in the seventies of last century, and remained until the rise of the decision-support systems in the nineties of this century, followed by the knowledge-based and intelligent systems. These new systems usually use mathematical models, mostly in Operations Research and Statistics. When you come to mathematics, do not argue the usefulness of Fortran.

[rase]

I still use Fortran because I use Fortran for nearly 50 years now, from Fortran II on early IBM computers to the actual standard supported by IVF. Although I am forced to use C/C++ once in a while no expert was able to convince me why I should give up the language I am most familiar with and which is suited best for my main field of application. I agree with all points put forward in the previous posts.

[Said_E_]

Hi all,

I have been in programming since the electro-mechanical accounting machine IBM 420 (old enough). Then I worked on the electronic machine IBM 1620 using Fortran II in early sixties. The application was in Operations Research (OR), which is pure math. Then came the DBMS in the seventies to satisfy the management needs for large data storage, retrieve, and reporting. From late eighties, decision support systems (DSS) began to rise, followed by knowledge-based and intelligent systems. These systems came to satisfy the management needs for decision support, best management practices, and innovative information systems. They are database systems empowered by mathematical models, mainly in OR and Statistical methods. To process mathematical models, no programming language is better than Fortran. I think this is in brief one of the answers to the question "why Fortran is to be used in business nowadays".  I myself have developed a DSS called "Shipping Optimisation Systems" to optimise cargo mix selection, allocating ships to trade areas, and appraisal of new ships. The system uses MS Access to capture data and Fortran own code to optimise. 

Best regards all.

Prof. Dr. Said El Noshokaty

[andrew_4619]

Why fortran: 

My application was initally started in the early 80s on VAX fortran. And has at various times been on DEC, Apollo and HPUX hardware before being standardised in the PC via Microfoft Fortran, Fortran Powerstation (boy was a glad of that Phar Lap DOS extender....), Digital, Compaq and now Intel fortran.

1) Why change code that works; 2) Easy to program and understand; 3) Good support; 4) No real limitations 5) Not stale (at Intel) still being improved.

[John_Campbell]

My experience with Fortran began 40 years ago when I first learnt Fortran IV.

I have also been trained in many other languages, including Algol, Lisp, Cobol, Pascal, C, C++ and Visual Basic, however none of these provided me with the efficiency of software development and the accumulation of libraries of numerical routines that Fortran has enabled me to achieve.

I first learnt my Fortran programming style, by copying other software packages I have worked with. Tektronix Plot 10 graphics library taught me the concept of defining a dataset and then a hierarchy of small or simple routines to achieve a structured approach to a much larger solution.

My experience adapting a number of 1970’s numerical codes from the University of Berkeley from Control Data to Pr1me and Vax minis again demonstrated to me the importance of clear and concise code and data structures, which reduces the development time. Coding is not about being smart, but keeping it simple. In this coding environment, REAL*8 says more about numerical precision than any of the newer KIND approaches.

The introduction of Fortran 90/95 has been a significant change in my use of Fortran, with the standardisation of many of the industry extensions that evolved from the limitations of the Fortran 77 standard. Where previously, data structures were based on COMMON include files, MODULEs and derived types have provided a new programming framework for defining the key data structures to base program development.

My coding approach is based on a subset of Fortran 90, minimising the use of coding structures that I have found more difficult to debug. These include Pointers and many of the new data structures available in F2003 and F2008.

My coding approach has been a pragmatic approach to bug elimination, to build a stable library of routines. In my experience, Fortran, combined with a debugger has been the best language to suit this approach.

I have rarely developed code to deliver a pre-defined set of capabilities, but rather evolved a code to expand on capabilities to identify a solution to larger problems. The best outcomes have been an evolution to a new market solution.

I am always amazed with large software development projects that stall because they appear to have not developed the key solutions, building blocks to address the problem. Solution concepts should not be so complex to require the hundreds of man years of development that their budgets devour. These are not developed in Fortran.

Fortran delivers solutions, but don’t be blinkered and not see the potential.

John

[atru]

I have not enough time and money in order to write again the new codes in other languages. Fortran is a very save money language.

[TimP]

Yes, Fortran is particularly cost-effective for applications where there is a requirement to approach performance capability of CPUs. 

Intel(c) C++ or Cilk(tm) Plus afford opportunities to match Fortran performance by application of #pragma etc. but many competent developers forgo use of even C99-like features in interest of better maintainability.

I saw a recent survey which said the vast majority of current Fortran programmers, even younger ones, are self-taught (as it was when I started),   I don't see any possibility of these people achieving the results they do by any alternatives.  I can't vouch for the credibility of the survey, but I don't place any confidence in surveys producing contrary results.  If this thread counts as a survey, it's certainly biased by self-selection.

[John_Campbell]

Tim identifies a significant issue, being the training of Fortran programmers. In 1973 I was fortunate to do a third year BSc major in Computer Science, which focused on Fortran and numerical methods. Five years later, the course had changed to a more operating system focus and minimal numerical methods. While some would agree that this change reflects the change in focus of the field of computer science, the background behind the numerical methods approach, which is important for the computation approach is no longer being taught.

In my work experience, there are very few who even understand what I do. When I stop doing the work I do, others will have to resort to a "black box" approach, or probably not do the work at all. The pessimistic view is they will attempt to apply simplistic packaged solutions to problems and pay for a less optimised solution. The optimistic view is they will find new ways to describe the problem and solve it in a different way.  It's disappointing to see all the Fortran skills and solutions being lost, as few are continuing the adaption of numerical methods to real problems.

For a business model using Fortran, maintenance of the developed code is an important consideration.

John

[onkelhotte]

Why we use Fortran:

When I started work about 10 years ago mainly Fortran was used in my departement. There was a lot of old code originally written on an UNIX system and it could easily be used under Windows and the DEC Fortran compiler. As a GUI we used QuickWin. I find it very easy to read.

We still program in Fortran because it is fast and there are a lot of built in mathematical functions. Btw. colleagues of mine are now rewriting their code to get away from IMSL because of the new license model...

Nowadays we´re changing from QuickWin to WPF programs that use a Fortran DLL. I tried to reprogram some subroutines in C# but it was so much slower.

And this forum is a very good reason to stay with IVF.

Markus

[dboggs]

The main reason I stick to Fortran is stability. We are still using (engineering wind tunnel testing) a large suite of programs developed in the mid 80's, using MS DOS Fortran, ranging from about 5,000 to 20,000 lines per. There were years of testing and bug fixing. It is only now coming to an end to its useful life, due to hardware pressures and user gui expectations. But with the advent of F90, and the IVF compiler + support, Fortran is a viable means of revanping this existing code base with little effort and vastly increased usability. One important aspect is that many of our programs plotted data using an old graphics primitive library, Halo, with which we created (usually) x-y plots that were really better than anything else we could find at the time. Now, thanks to Quickwin and its collection of graphics primitives, the Halo code was really pretty easy to convert. This is a testiment to stability.

My biggest problem now is dealing with an onslought of young engineers and IT types who learned various "modern" languages, and there are now four different camps for software development in the company: Fortran, VB, Labview, Matlab, and the "Language of the Month Club." The cost of redeveloping code in any of these is costly and scary. It's unfortunate that Fortran is not emphasized in school any more. But, this is because engineers are taught problem-solving tools, not long-term production-level high-performance tools, and Matlab fits that bill pretty well. It's not good for long-term stability. Joining this modern trend probably means redeveloping our code base every 10 years, not every 35 years. How wasteful and risky of bugs.

My biggest concern is the future of Quickwin. Without it I would not be using IVF Fortran. I have no interest in learning to write complete Windows applications. Quickwin could be improved a lot, but I perceive that Intel's committment to it is pretty much maintenance and not development.

[FortranFan]

Excellent comments - thank you to all contributors thus far.

It'll be wonderful to hear from more users, especially from a) those who have recently started programming and thus can "leap frog" to modern Fortran for their code and b) those who may have recently started large program developments almost from scratch using Fortran.  By recent, I mean roughly 5 years or less i.e., from the time many Fortran 2003 features started appearing in major compiler versions.

Is it true some major weather prediction models are being developed back in Fortran after a long and expensive excursion to C++?

[jimdempseyatthecove]

I’ve used FORTRAN since 1968 – FORTRAN II on DEC PDP8-L, then a variant FORTRAN-D on PDP8-I and FORTRAN IV also on PDP8-I. I would intermittently use it until about 2004-2005, when I started using Intel Visual Fortran for simulation work. The _the_ (bold underline) driving factor for choosing IVF over competing products was Array Visualizer/Array Viewer. While with a few band-aids I can manage to continue to use the Array Visualizer in my simulation code, I miss the ability to have this as a supported product. I do not use it for debugging (read I do not care if it is integrated into VS), however I do use its API  to drive visualizations. F90 and later with modules and OpenMP I could not do without. The newer F2003 and later features may be nice to have if you were designing an application from the ground up. I would not go to the effort of changing a working application for the express purpose of using a new feature.
Where I would like FORTRAN to evolve towards is to bring back Array Visualizer (or other equivalently implemented HDF5), and add templates (see project on SourceForge called PyF95++ with Blockit classes).

Jim Dempsey

[nvaneck]

First learned Fortran in 60s, then assembler language. When PL/1 came along, it looked too messy.

Fortran always easy to read, if you used good programming techniques. C always looked very messy whenever I looked at code examples, and I found it hard to read.  Since we'd developed assembler routines to provide certain function like memory allocation and for speed, there was no reason to look elsewhere.

With imporvements to Fortran and great optimization, assembler language programs are no longer needed, and everything I ever need to do is available in standard Fortran in clear forms.

[TimP]

I've been working off and on this year on porting the Coamps application to many-core architecture.   My guess, with limited personal experience, is that weather forecasting applications have settled down in their choice of base languages, if not in the way in which parallelism is implemented.  Coamps is not exclusively Fortran but it's mostly F90.  It's currently MPI with lots of disused OpenMP directives which don't match the current source code; I suppose that would be taken by some as a demonstration of the disadvantages of overlaying parallel libraries.  Recent experience appears to confirm the choice of certain weather modeling developers to employ multiple levels of parallelism (MPI/OpenMP/auto-vector).

[glwilsonberriehill_c]

I have been employed in the defense industry since 1983, working as a PhD mathematician within an environment of physists and electrical engineers. I continue to program using a Windows OS because its what I'm familiar with and because many of my co-workers also use it. Before windows existed, I used DOS on an original IBM PC.

Although most of the new codes I develop are written in MATLAB, I still use FORTRAN now and then.  The main reason for this is simple: legacy code.  I continue to work with computational electromagnetic (CEM) codes that are written in FORTRAN.  It's often a better use of my time (i.e. cheaper) to modify an existing CEM FORTAN code than it is to rewrite it from scratch in some other language. Other reasons include familarity and lack of a requirement to write or re-write code in some specific language.