Is FORTRAN still an active language. Should we convert to a "newer" language?

[jlgilber]

I was asked this question as part of a risk analysis that was done on our systems. For anyone who is willing, I would appreciate a response to this message with the type of business that you are in. Any additional information, number of applications written in FORTRAN, etc would be helpful as well. I work in the electric energy industry.

Thanks in advance........

[wfroese]

I can't wait to read the replies that you get here. :-)

My practice recently went through a risk analysis of our FORTRAN/VB apps that support our Defined Benefit Pension practices. We have a number of them where the 'work' or the goal of the app is to get the data and settings to run through the FORTRAN calculation engines.

I can tell you that a number of pension consulting firms have FORTRAN calculation engines for various purposes.

In the end, my firm decided that while we could keep these applications we would - they are the best choice. Our fall back would be if the team scattered, we'd ditch our great apps because it would be too hard to get people with pension + FORTRAN knowledge who could pick up the program. There are commercial versions in the marketplace that would suffice.

I can tell you that I haven'tstarted 1 new FORTRANcenteredapp since .NET arrived in 2002 and I wouldn't start one. I also am not going to leave the code I have in FORTRAN - it has been pounded on for a decade and is proven and that is worth a lot. It is fast and it is right and that's what you want for calculations. My development plans include C#, VB.Net but they will be calling someFORTRAN components because it makes sense still but anything new will sacrifice the speed of FORTRAN for the legions of C#/VB.NET people available.

[Dishaw__Jim]

In my field, scientific computing, Fortran is still widely used and Fortran 95 definitely has reversed the downward trend. The advantage that Fortran holds in scientific computing is twofold. First, there is a great deal of well-tested codes that are written in Fortran. Second, the notation used by Fortran lends itself to expressing mathematical constructs efficiently without extraneous code; for example, consider the simple operation of initializing an array in C and in Fortran

C

for(i = 0; i imax; i++) myarray = 0.0;

Fortran

myarray = 0.0

Sure, both languages will generate the same machine code, but why type extra letters.

Another point to consider is that some legacy codes have undergone a lengthy and expensive process of being validated. For example, in the nuclear field there are codes that have been approved by various regulatory bodies and if you want to write a new code you would have go through the validation process.

[Steven_L_Intel1]

We see our customers doing a lot of new development in Fortran across all sectors of the market.

[brianlamm]

Not only that (i.e., Steve sees Intel customer Fortran development activity rising), but I would suggest that when the object-oriented features of Fortran 2003 are implemented (esp by Intel in my case), the Fortran development acitivity will steepen still further.

Take a look at "Fortran 95/2003 Explained" (currently the only book commercially available describing Fortran 2003 standard), taking account of the publicly available errata, for a concise (like pure acidconcise) desciption of the new features of Fortran 2003. As Steve has noted elsewhere, the change from Fortran 95 to 2003 is an even greater leap than from Fortran 77 to 90 (or 95), so be willing to wait I don't know how long for the full feature set of 2003 to be implemented. But I think it will be well worth the wait.

I personally would like to see a forum topic, or a whole forum,started focusing on Fortran 2003 implementation of Design Patterns, especially the Strategy pattern, and Fortran object oriented development in general. Patterns, and object orientation implementationsusing Fortran 2003 in general, will require more work (lines of code) than in, say, C++. That will be the "price" of using Fortran 2003 for object oriented development, but the payoff will be better optimization since Fortran 2003 standard is more restrictive, making it harder on compiler implementors, but, hey, that's why they get the big bucks!

-Brian

[Intel_C_Intel]

Hello,

Writing efficient code with a high degree of readability may be difficult. In particular if the code is going to take maximum advantage of "modern" processor features such as branch prediction, cashes with hardware prefetch, out of order execution cores and intraregister vectorization. No language has been deliberately designed to take advantage of these features (as far as I know), and it is a trend that the newer languages are the least suitable to gain maximum performance. By inspecting executables produced by various languages, it seems that good old Fortran 77 produces the most elegant and efficient .asm code resulting from elegant programs written with a high degree of readability. If you ask the Intel Fortran 9.1 compiler to produce "Assembly with Source Code" program listing, you often notice a high degree of readability in the .asm code also - actually it is not unusual to observe one .asm line for each Fortran 77 statement. Not so in many modern languages where one single line in the code may result in tens of .asm lines, clearly inefficient and an indication of poor software engineering. In particular in the implementation of physical and mathematical equations, newer languages such as C++, with too compact syntax may lead to ambiguous hard to read software that is difficult to optimize for the compiler. To ease thejob for your co-workers (that must read your code) and the compiler - use good old Fortran 77!

Lars Petter

[jlgilber]

Steve,

Do you have a "futures" list for the compiler? What is scheduled for upcoming releases, etc?

Also, What is the approximate number of current users?

Thanks,

Joel

[Steven_L_Intel1]

Sorry, can't disclose either of those.