The future of Fortran

joseph-krahn · ‎03-07-2007

Modernization of Fortran has been hampered by a combination of bureaucracy and too many archeophiles on the Fortran committees. F2003 and F2008 are finally overcoming some (but not all) of the worst problems. Is it enough for Fortran to regain status as a 'real' programming language?

My current opionion is that Fortran is superior for math, and horrible at almost everything else. C++ can work well for math, but it seems that it will always have the added complexity of things like multiple incompatible matrix classes. It makes sense to me to use Fortran in conjuction with some other language (compiled or not) to deal with all of the non-math stuff like file parsing.

Joe Krahn

Steven_L_Intel1 · ‎03-08-2007

There's always a thread or two on this going on in comp.lang.fortran. I don't know what you mean by a "real programming language" - a language used in millions of applications around the world is real to me.

I don't believe in language wars, nor in the idea that one language should be perfect for all applications. Fortran has its strengths and weaknesses. So do C++, Java and all the others. That said, I find I can do most everything I want in Fortran and I see lots of applications from others who use Fortran in "non-traditional" ways.

jimdempseyatthecove · ‎03-09-2007

I agree with Steve.

A "real language" is, IMHO, use by a community of programmers (speakers of the language). No different from spoken language. Swahili is a "real language" whereas Jabberwocky might not be consideres a "real language" although some forms are spoken by large numbers of school childeren (could have been in the millions at it's peak).

There are some features found in some languages that would be nice to migrate into other languages (barring opposition by the Luddites of the language on the standards committee). Better constructor/distructor in Fortran might be nice. And so would somethings that are simple and seem obvious in other languages, such as scoping. I cannot count the number of times I wish I could use { and } with temporary variables declared after the {.

Another thing that is not found in C++ nor Fortran but was available in other languageswas local scope subroutine/function calls. i.e the variables of the current scope are visible to the called subroutine/function in addition to the parameters passed in the call. But this smites in the face of those in favor of containing access. A comprimise would be to require declaration of variables used but not formerly passed in the code generated.

Jim Dempsey

carlgt1 · ‎03-15-2007

as a primarily C++ fan & advocate I'll give my two-bits (whether you want it or not). There's nothing really wrong with Fortran -- I think it just gets bad press because it's old, "unhip" (primarily in not being object-oriented, which I guess goes back to being old! ;-), and there is a lot of bad code out there because it's primarily scientists and not software engineers who use it. So it's probably about as appealing to computer geeks these days as COBOL. But having worked with it regularly over the past few years (although primarily in calling things from C++), and seeing a lot of good science code in Fortran (and a lot of sloppy code that somehow does the right thing :-), I think that Fortran has a pretty good future. I think it's "navigated time" well compared to say, Windows.

Lars_Petter_E_1 · ‎03-31-2007

The obvious advantage of FORTRAN is allthe limitations. This makes it difficult for the developer to write code that is not transparent for his/hers co-workers or the compiler. In my experience transparency is a good thing in software development, as it reduces the probability for bugs and also makes it easier for the compiler to make assumptions that may lead to fantastic optimization compared to all other languages. In fact FORTRAN is an excellentillustration of the fact that simplicity generally is a good thing, Occam's Razor: All things being equal, the simplest solution tends to be the best one.

http://en.wikipedia.org/wiki/Occam's_Razor

joseph-krahn · ‎04-02-2007

By "real" programming language, I mean primarily one that is considered worth teaching in college. Most computer science departments see Fortran as just a dead-end legacy language, much like COBOL. There are still lots of COBOL users, but I think that really is just due to legacy code, not because it is useful. The view that Fortran is just a legacy language is partly due to computer-science biases, but there are also many things that are just cannot do in Fortran.

The problems I see with Fortran is that non-math things can be very difficult. In most cases, it makes sense just to do these things in another programming language. But, Fortran Standards have resisted standardizing C compatibility, which is the most important tool for doing non-math things in another programming language. So, you are stuck with poor non-math functionality, and no portable way to get these things done outside of Fortran.

In general, the !DEC$ extensions have gotten around these problems. IMHO, all of these !DEC$ extension hacks is an indication that Fortran is an incomplete language. Making these things part of the language instead of an add-on hack will (I hope) make Fortran more respectable. I'm not saying Fortran needs to be a complete "application" programming language, just that is has taken a very long time to incorporate features that a lot of Fortran programmers obviously find important.

Lars_Petter_E_1 · ‎04-03-2007

I have seen many attempts to use a single language for everything, and all these attempts have failed completely. Thus, why not use the languages for what they are meant to do? Take C++ for example. Recently we made a nice little program in plain C using Intel multimedia intrinsics that solved a certain set of problems in about 70 seconds. Now, we had some competitors out there that used C++ and typical C++ paradigm programming style, well they used about 3 days to solve the same problem set. Of course they were unaware on how to use efficient hardware instructions efficiently (like 128 bit "pand" that only take a single clock cycle ), but this is sometimes a result of the top-down focus among most C++ developers. So, yes I agree, you cannot use a single languageforeverything, you adapt the language to the problem at hand.

In terms of readability, you may reduce the readability of the implementation enormously if you use one language in a task where another should have been preferred. So it is much better to pragmatically view the various languages as separate tools in your toolbox. Sure, there are religious fundamentaliststhat want to use the hammer to fix everything, but you would not let those people fix your house would you?Why notteach the students in college that there are many commercially successful software applications that use a mixture of languages, for example C++ for GUI, C for TCP-IP, FORTRAN for supercomputing - in the same executable!

joseph-krahn · ‎04-03-2007

I think the summary of what I am getting at is that Fortran is definitely not a general purpose language. But, it has been difficult to portably use Fortran for it's strength along with aone or more complementary languages. Until now, doing this has required a lot of non-portable hacks. I have seen many projects that get rather ugly when some things need to be done outside of Fortran, but still trying to maintain portability. All of this non-portable hacking contributes to the general dislike of Fortran by computer-science people.

With ISO-C-binding finally here (among others), mixed code with Fortran is portable and efficient. This should make Fortran an attactive math 'engine' even for people who primarily program in some other language. But, is it enough to regain popularity in the general computer science community, or are they just stuck on the general fascination of new languages, and that old means obsolete?

Lars_Petter_E_1 · ‎04-03-2007

With ISO-C-binding finally here (among others), mixed code with FORTRAN is portable and efficient.

I agree! I am not familiar with ISO, but quite many real life commercially successful applicationsworldwide use FORTRAN 77 for supercomputing and modern C++ for the rest (including GUI), and to me such mixed-language-programming is a pretty standard, portable and platform independent these days (has been for years to me!). I am not sure about college and universities, but it would be nice if they would prepare the students for the real commercial life where many languages usually are combined pragmatically to achieve the desired results.

I can understand that generality is nice from a computer science point of view,

Fortran is definitely not a general purpose language
the general dislike of Fortran
is it enough to regain popularity in the general computer science community
or are they just stuck on the general fascination of new languages

However, such considerations may be of less importance in the real commercial life where one has to take a more pragmatic point of view. It is the results that count simply because the customer does not usually pay attention to what kind of language that has been used in the application at hand. I would focus more on the popularity and fascination for the final software product than for how it has been developed. OK. I can admit that I love FORTRAN as language in math and physics supercomputing, but frankly speaking this is irrelevant if the final software is not user-friendly, robust, bug free, fast and priced correctly.

My experience is that more C++ developers than FORTRAN developers have a tendency to take the role of the customer, thus focusing more on the needs of the developer than the final customer. This is interesting, because what is good for the developer is not always good for the customer. It is rather the opposite that is the case,kind of Murphy's law: what is convenient for the developer is exactly what is notconvenient for the customer. For example, C++ exception handling may be nice for the developer in order to catch bugs, but the user may be seriously annoyed if harmless bugs repeatedly terminate critical applications.