Slashdot Mirror
Is GNU g77 Killing Fortran?
goombah99 asks: "I've come to believe that the existence of GNU g77 (and f2c) is holding back Fortran development. You might think that a free-ware compiler would be good for promoting the language. But it's not because the GNU flavor does not implement the de-facto standard DEC extensions to the language that give it dynamic memory allocation, pointers, and data structures. Without these Fortran 77 is indeed barbaric, but with them it is quite pleasant to work with. The problem is everyone writing new code is now afraid to use these commands in because of the desire to have their applications compilable by the teeming masses who may not want to pay $500 to $1000 dollars for a professional Fortran compiler (all of which do implement the DEC extension). F95 is being held back by the same considerations. Do you agree? Does anyone have some library extensions or pre-compilers that provide these capabilities to g77?" Are the DEC extensions so widespread and common that language survival is dependent on their inclusion, as the submitter suggests, in "every professional compiler". Assuming there aren't comparable features already available in g77, are there plans on eventually implementing similar?
20 C++ faster than Fortran
But it's not because the GNU flavor does not implement the de-facto standard DEC extensions to the language that give it dynamic memory allocation, pointers, and data structures. Without these Fortran 77 is indeed barbaric, but with them it is quite pleasant to work with.
You can mock Fortran 77 all you want but the "barbaric" striped-down version can be highly optimized. And for a lot of the legacy scientific code out there, you just don't need dynamic memory allocations, etc. If you really do need all these fancy, modern features, why the hell are you using Fortran 77? Fortran 77 is a simple yet highly effective, stripped-down language that is appropriate for a limited number of applications. But it does those applications really damn well. Don't blame Fortran 77 if you're trying to use the wrong tool for the job.
GMD
watch this
There's already a team of very capable -- and young, not ancient/retired/whatever -- programmers implementing the Fortran 9x language, which defines some really interesting constructs. The current plan is for an initial release as part of 3.5.
Fortran 2000 has a spec, but I don't know of any implementations for it.
As far as "why is it still being used at all" comments, two words for you: no aliasing. The same reason why numerical computation in Fortran continues to chew C's head off.
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
You can develop software in any language. Fortran, C, Visual Basic, Assembly, ...
99% of the problem is the programmer not the language. Every language has an advantage in its specific area. VB/Delphi Quick & Dirty Interface or Prototype (quick development time). C/C++ Portability & Speed of Program. Assembly True low level programming. Wait what is fortran used for again? (lol just kidding). Excellent math modeling for quick and dirty precision calculations (I'd still use C because I've never used Fortran).
I guess g77 is holding it back because that is one of the reasons I've never used it. I thought there was a Fortran 85 or 90 spec as well?
Boomer Sooner (way to choke one off early Tejas)
Haggle over the technical merit of g77 all you want, but free software is not the same as "free-ware".
Digital Citizen
How can anyone think that the free availability of a vital resource impedes the progress of anything ? Is the availability of free C,pascal,forth etc implementations killing off those languages. Is the availability of GCC for win 32 stopping anyone from using Visual C ? Is the availability of freepascal killing delphi ?
The answer is no. A free implementation of fortran makes it that much easier for the language to be taught. If there are people that know the language they will use it. If people use the language it will grow and develop.
If you wan't to know what's hurting fortran you might try readin Dijkstra's "Goto Considered Harmful".
You are looking at the issue from the wrong perspective. Unlike a software engineer, scientists does not consider the software they write a final product. Their product is the result of the computation performed using the software. That's what brings them grant money. Thus, they would like to spend as little time as possible writing software and dedicate most of their time to interpreting those results. Since most of the numerical libraries out there are written in FORTRAN and that they are already familiar with the language, I think FORTRAN will remain their darling for a long time. It's a fact of life, not a matter of policy.
By the way, most of them use commercial compilers rather than g77, because they need the optimizing features which g77 does not provide (think parallel computing).
"You can't allow somebody to commit the crime before you detain them." [Condoleezza Rice]
Yeah... I thought the CS community at large mostly knew about this. Okay:
Fortran specifies that Thou Shalt Not Alias, so in the example on the page that you linked to, the function-calling programmer, the function-implementing programmer, and the compiler can all assume that everything refers to non-overlapping memory, and can optimize the hell out of read/write memory accesses.
When Dennis Ritchie designed C, it was a deliberate decision to not prohibit aliasing. (C's ancestor languages may have allowed aliasing as well, and DMR just decided to continue that; I don't actually know. But the question was brought up and considered; it's not an accident.)
When C was first being standardized by ANSI, a really sloppy proposal was made to add a 'noalias' keyword. It was so bad that DMR sent a public letter to the ANSI committee stating, "noalias must go; this is non-negotiable." So C89 has no way of restricting aliasing.
C++98 and C99 do, sort of. C99 added the __restrict keyword to the language. C++98 left the core language alone and defined a library type, std::valarray, that is free of aliasing by definition, opening up a number of optimization possibilities.
Valarray didn't quite work out; its design is semi-broken. Far more hopeful is using expression templates to expose more of the numerical computations to the compiler, so that more optimizations can be done on visible numbers. Check out Blitz++ at oonumerics.org for an example.
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
Yeah, there's a lot of that going around in the open source world. I've heard of this other project that's stifling growth in a major segment of industry by not implementing the de-facto standard extensions that its commercial competitor uses. You might have heard of it, it's called Mozilla.
I admit that I haven't touch FORTRAN since about 1985, so forgive me if I'm not exactly up on the state of the art. From a little googling, it looks to me like g77 is pretty much an orphaned project. This is free software, man, developed and supported by the community. Have you considered volunteering to fix the parts you think are broken? Or volunteering to work on the f95 compiler effort?
Chelloveck
I give up on debugging. From now on, SIGSEGV is a feature.
What is really killing fortran is the perception that fortran == f77. Tell someone you program
in fortran, and they immediately think of old,ugly f77.
I write code (both reasearch and commercial vibration analysis) in fortran90/95 every day - I
use modules, I use pointers, and I get great performance. A few things I also get:
1) clean, neat code that is easy to read by non-programmers.
2) Array bounds checking by the compiler - try that with C++. Array bounds checking saves me
huge amounts of time in development.
3) Compiler checking of function calls, via encapsulation of functions in modules.
4) Easy use of BLAS and LAPACK routines for real computational work.
5) The actual function definition used for the function prototype - I don't have to maintain a
separate prototype for my functions to get the advantages of prototyping!
Fortran isn't perfect (yet). It still lacks the ability to make a function part of a data
structure (ie, classes). It current i/o abilities still suck. It's ability to handle characters and
character strings is terrible. But it does have advantages other than producing fast code, and it
isn't your father's fortran77.