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?
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
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)
The last time I programmed in Fortran it was still Fortran IV. (Oh, wait, I did write a version of "Asteroids" for a VAX with a graphics unit and AD/DA hardware in DEC's Fortran 77 -- but that wasn't serious programming.)
;-)
When I wanted structures and records and fields (oh my!) I went with PL/I or Pascal or C or C++ or Java (in roughly that chronological order). Let it go. If you want to do Fortranish things, use (standard) Fortran. If you want to do Pascalish or Cish or Adaish (etc) things, use that language.
There's probably a corollary of Henry Spencer's law about ignorant OS designers reinventing Unix (poorly) that applies to programming languages, although I haven't quite figured what the "target" language (the way Unix is the target OS) is. (Probably Algol68
-- Alastair
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]
Sure, but it expands into C++ code. You still need a very wise C++ compiler to turn this into efficient machine code.
A decent Fortran compiler knows more about the original statement than the C++ compiler can, and also, a Fortran compiler's number one reason for existence is to optimize array accesses.
A C++ compiler is lucky to correctly compile all of the heinous complexity of the C++ language, much less aggressively optimize this type of array access.
I'd be much more impressed if the poster had shown the resulting machine code.
You mean, write Fortran-style programs in a crippled sub-dialect of C?
Plus, how many C compilers are made to optimize for this case that is extremely common in Fortran, but extremely rare in C code?
Fortran compilers are the best compilers for Fortran programs. C compilers are best for C programs. Fortran compilers can be expected to perform poorly on "C-like" structures, and C compilers are likely to perform poorly with "Fortran-like" programs.
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.
You've started with a conclusion (g77 is holding back the adoption of F95) then found evidence to support it. However, if we look at the situation logically, a better conclusion would be that non free software is holding back the adoption of F95. F77 is being more widely used because there is a free compiler available for it. In conclusion, the finger should be firmly pointed at vendors who refuse to release an open source or free as in beer F95 compiler.
It's impossible to write a complex program without using GOTOs
I call bullshit on you. There is <b>nothing</b> about fortran that makes GOTOs any more necessary than they are in C (which is an argument in and of itself... however I come down on the side of "never use them").
I taught two beginner's programming classes between 1995 to 1999, one in F77 and one in C (with the last week talking about C++). Apart from the lack of pointers and structures, F77 has (essentially) all of the language structure C (or any other procedural language) does. I never allowed my students to write GOTO statements, and it was never necessary (beyond the same caveats C programmers have when saying that). As a side note, we got significantly further in programming with the fortran groups than the C groups, despite the fact that the fortran class was taught to freshman chemial and mechanical engineers, and the C class was taught to electrical engineers (who, as demographic cross-section, had somewhat more of a bent towards programming to begin with).
It's true that C is made far more capable (and difficult to learn) because of pointers. It's also true that the lack of structures makes F77 a bit of a pain in the butt at times (but not in any way less capable). However, complex data structures are still <i>possible</i> in F77, if a pain in the ass. I've written binary search trees, recursive descent parse trees, and linked lists in vanilla F77 (no DEC extensions). Granted, the F77 idiom for doing this kind of stuff is really kind of sad. However, I could argue that there are similarly lots of things that C programmers do every day which are horribly fugly because they can't use the idioms of perl (for example).
Anyway, maybe it's pointless to argue because, in the end, I really... <b>really</b> wouldn't recommend anybody program with F77 any more.
:Wq
Not an editor command: Wq
Let me get this straight:
1) People don't want to pay $500-$1000 for a compiler.
2) The existance of g77 means that they don't have to.
What's the problem again? Shouldn't people be able to make a ``less featureful, less money'' decision? (..and that totally ignores the other values of having a free-as-in-speach compiler).
The only reason to learn Fortran today is to work with old code. The old code is invariably written in F77, since it is without a doubt from the 70s itself.
there is no good reason to develop a new application on fortran today.
well, except for massively parrallel calcuations using parallel optimizing compilers.
but write it in F77 anyway, it's all you need.
if you really need dynamic memory or pointers, write it in C. it's faster, easier to optimize with plain gcc, and also from the 70s.
or just buy freaking matlab or mathmatica or something.
Tetris rules.
The parent is dead on.
FORTRAN in its modern instantiations (F95) is completely unlike F77.
I've worked on lots of numerical computing projects, and have been attracted to many of the features of FORTRAN.
Yes, you can achieve many things in C++ through the use of templates and libraries like Blitz, and yes C++ is comparable in speed to FORTRAN.
However, I still think FORTRAN gets it right with numerical computation. For all the gains C++ has made in numerical computing, it still doesn't have the resources--in terms of libraries, etc--of FORTRAN. All the benchmarks I've seen suggest that FORTRAN is still a hair faster than C++. And the syntax of even the best C++ matrix libraries doesn't compare to FORTRAN. FORTRAN has numerical computing built right into the language, and anyone who has dealt with these things can't really deny its appeal that way.
And yet, whenever I sit down to work on a project, C++ wins. Why? Because of the great features of C++ not available in FORTRAN? Not really, because most of the things I want are in F95.
The reason why I go to C++ again and again is simply because I don't have a F95 compiler available for me to use.
So the choice comes down to C++ versus F77, when it should come down to C++ versus F95.
If a F95 compiler were avaiable, I would probably use that. But it's not there, so I use C++.
I personally think the FORTRAN community's biggest obstacle right now is its identity crisis. There's really no such thing as programming in "FORTRAN." You either do F77 or F95. And yes, they're both FORTRAN. But they're not the same language.
FORTRAN advocates have got to stop using F95 as an argument against using C++ when F77 is what people actually use. F77 is woefully behind. F95 is not. But very few people, even in the FORTRAN community, use F95.
How are you going to attract young FORTRAN developers when they can't compile their code? Just compare the number of free F95 compilers to the number of free C++ compilers, or the number of Java compilers.
FORTRAN isn't being killed off by g77. The lack of g95 is killing off both of them.
Heh, thanks.
;-)
But that's almost a tautology: any C or Fortran program that doesn't contain "an ad-hoc, informally-specified bug-ridden slow implementation of half of Common Lisp" is clearly not "sufficiently-complicated"
-- Alastair
Youre missing the point. The point is if you wat to write and share portable code you dont want all the people who get it to have to buy a compiler. Imagine if Linux was not distributed with a gCC complier so you have to buy a compiler to compile linux. This would be unacceptable. Now suppose that the only free complier was K+R C, with no extensions. Would people be writing all applicaitons in K+R C rather than say java or c++ because they had to have it able to be compiled by the end user. yes they would. That's the problem with issuing non-standard compilers.
Now as for the second part of your screed, people with big computers preumably are not running data bases, word processors or games. They are doing numerical calculations. and they are not pro prgrammers they are sceintist. So they want results not well designed programs. Fortran is the language of choice for multi-processor ad hoc programming.
Fortran knows how to parallelize it self. the language explicitly indicates to the compiler if it can ignore loop order dependencies, and can factor out contisionals and if subroutines will change data values. Memory is stored in predictiable fashions and thus can be shared more effectively.
So if you have a big box and are using C++ you may not be getting all the benefits you could from your investment.