Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
GNU is Not Unix Programming IT Technology

Is GNU g77 Killing Fortran? 195

Posted by Cliff from the it's-just-a-flesh-wound-look-at-FreeBSD dept.
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?
This discussion has been archived. No new comments can be posted.

Is GNU g77 Killing Fortran? More

Is GNU g77 Killing Fortran?

Comments Filter:

  • 10 GOTO 20 (Score:5, Informative)

    by Dancin_Santa ( 265275 ) <DancinSanta@gmail.com> on Tuesday September 16, 2003 @07:50PM (#6981406) Journal
    20 C++ faster than Fortran [iu.edu]
    • That should be:

      20 CONTINUE
      25 C++ faster than Fortran [iu.edu]

      Remember, jumping to a line number that's not on a CONTINUE statement can break things. :-P
      • I made the switch after that Physics course that required Fortran. I haven't used Fortran since, and I haven't looked back.

        I learned Emacs in that course as well. I haven't used that since, either.

    • Re:10 GOTO 20 (Score:4, Interesting)

      by Spy Hunter ( 317220 ) on Tuesday September 16, 2003 @09:37PM (#6982161) Journal
      Wow. That article is awesome. This code made my jaw drop:

      const int N = 64;
      Array<double,3> A(N,N,N), B(N,N,N);
      Range I(1,N-2), J(1,N-2), K(1,N-2);

      A(I,J,K) = (B(I,J,K) + B(I+1,J,K) + B(I-1,J,K) + B(I,J-1,K) + B(I,J+1,K) + B(I,J,K-1) + B(I,J,K+1)) / 7.0;

      You can do that with C++?!? And it's super-efficient!?! The article explains that this code actually expands automatically into this loop that traverses the arrays in a convoluted manner designed specifically to improve cache-hit performance. All this complexity is hidden inside the library. Now I see what all these people have been raving about with template metaprogramming and expression templates.

      Seems to me that template metaprogramming is a rather awkward way to go about these things though. Couldn't you design a language that had features specifically designed to enable this type of in-line compile-time code expansion?

      • Re:10 GOTO 20 (Score:5, Insightful)

        by jaoswald ( 63789 ) on Tuesday September 16, 2003 @09:56PM (#6982317) Homepage
        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.

        • Re:10 GOTO 20 (Score:4, Interesting)

          by Spy Hunter ( 317220 ) on Wednesday September 17, 2003 @02:45AM (#6983712) Journal
          Why do you need to see the machine code? Doesn't the performance of the compiled code speak for itself? He benchmarks the code against hand-optimized Fortran code for the same task, and it beats Fortran. Did you even read the link?

      • Re:10 GOTO 20 (Score:4, Informative)

        by Dr. Photo ( 640363 ) on Tuesday September 16, 2003 @11:40PM (#6983040) Journal
        Seems to me that template metaprogramming is a rather awkward way to go about these things though. Couldn't you design a language that had features specifically designed to enable this type of in-line compile-time code expansion?

        There's something like that already, called ANSI Common Lisp. (Yes, I'm serious.)
      • Couldn't you design a language that had features specifically designed to enable this type of in-line compile-time code expansion?
        Us old farts call it APL ;)

      • Re:10 GOTO 20 (Score:2, Informative)

        by t ( 8386 )
        I've seen this before and its complete crap. Change the first line to
        const int N = rand();
        Then see how fast it runs. All that uber special loop expanding trickery usually doesn't work when you don't know the sizes of your arrays beforehand.
        • Yes, but it's no more than logical that compile-time optimizations don't work if you don't know these sizes at compile-time, isn't it.
        • I don't think that's relevant. In most circumstances, you ALREADY KNOW the sizes of your vectors, since they're fixed by the type of algorithm you're programming.

          In other words, in these 'most cases' each position in the vector is NOT a new sample in a dataset, but rather a new variable, or axis of variability, in an equation.

      • The article uses FORTRAN 77, not the modern Fortran 95 which has a concise loop syntax, which allows the compiler to generate the best code with no reliance on the compiler understanding correctly what the templates are meant to achieve.

        Equivalent Fortran 95 code:
        INTEGER, PARAMETER :: N = 64
        INTEGER, PARAMETER :: DBL = SELECTED_REAL_KIND(15,364)
        REAL(DBL) :: A(N,N,N), B(N,N,N)

        A(2:N-1,2:N-1,2:N-1) = (B(2:N-1,2:N-1,2:N-1) + B(3:N,2:N-1,2:N-1) + B(2:N-1,2:N-1,2:N-1) + B(2:N-1,1:N-2,2:N-1) + B(2:N-1,3:N,2:N-1)
        • Alas, I didn't think of the FORALL statement. I need some sleep. A more concise and readable version with the typo corrected follows.

          INTEGER, PARAMETER :: N = 64
          INTEGER, PARAMETER :: DBL = SELECTED_REAL_KIND(15,364)
          REAL(DBL) :: A(N,N,N), B(N,N,N)

          FORALL(I=2,N-1, J=2,N-1, K=2,N-1)
          A(I,J,K) = (B(I,J,K) + B(I+1,J,K) + B(I-1,J,K) + B(I,J+1,K) + B(I,J,K-1) + B(I,J,K-1) + B(I,J,K+1))/7.

          But so what? I'm following up on an old story anyway...

  • Want "modern" features? Don't use F77 (Score:5, Insightful)

    by GuyMannDude ( 574364 ) on Tuesday September 16, 2003 @07:51PM (#6981408) Journal

    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

  • Old age. (Score:2, Funny)

    by t ( 8386 )
    Seriously, that is what is really killing fortran. When I was in undergrad about ten years ago they had stopped teaching fortran and had switched to C. Since then everyone falls into a couple of categories. (1) Those who learned fortran first and still use it. (2) Those who learned C first and thus have no reason to ever use Fortran. (3) Those who are forced by their jobs to use Fortran.

    Of these, group (1) is all the old foggies who are retiring, leaving group (2) people to continue the work. Typically wh

    • Group (3) people are always desperately trying to migrate their projects to C.

      Hey! I resemble that comment...

    • I fully agree that Fortran is NOT for every day programming of word processors, opertating systems, games, device drivers, and GUIs, and that there is a resistance to learning it in schools these days. However I believe the Modern Fortran Language is a better choice for most scientific and numerical programming by non-computer scientists;

      Consider the following....
      perhaps the biggest complaint in the cutting edge of computing is that no one knows how to effectively program for multi-processors for ad-ho
      • course can be done in parallel if the compiler or OS, not the programmer, sees the opportunity on the run-time

        Is there any platform where this actually happens?

    • When I was in undergrad about ten years ago they had stopped teaching fortran and had switched to C.

      And now they've stopped teaching C and started teaching Java. Does that mean C is dead? Also, at Oklahoma State, Fortran 77 is still offered as an easy credit in the CS department, and Fortran 90 (and no other computer language) is a requirement for any engineer. It's not like Fortran has disappeared completely.

  • Eventually? How about currently? (Score:5, Informative)

    by devphil ( 51341 ) on Tuesday September 16, 2003 @08:05PM (#6981497) Homepage
    Assuming there aren't comparable features already available in g77, are there plans on eventually implementing similar?

    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.

    • What is this "aliasing" all about? Can you go into more detail regarding why fortran is better than C for numerical computing?

      Bare in mind that I have NO knowledge of fortran, but I do compile fortran code for people doing scientific computing. I can see that at some point in the future I will probably have to learn a bit about fortran. It would be nice to know why bother? :)

      Steve

      • Re:Eventually? How about currently? (Score:4, Informative)

        by Jerf ( 17166 ) on Tuesday September 16, 2003 @09:43PM (#6982208) Journal
        I went poking around on Google and could not find an answer in 30 seconds, so you are forgiven. ;-)

        I think this page on aliasing [c2.com] should answer most of your good question.

        Add to that page the fact that if a compiler can't be sure about something, the answer is typically to copy the thing it can't be sure about into a safe location, and either copy it back somewhere after the "unsafe" thing or explicitly check it for changes.

        For instance, if you're calling a function and the compiler can't know what it's going to do to the caller's registers, the compiler must painstakingly copy the registers out to main memory (well, it'll probably land in L1 cache but still it could be very expensive compared to the function itself), call the function, and copy the registers back in, whereas if the compiler can know it's a little function that only uses registers X and Y, it can only save those. If you're calling lots of little functions, this can add up.

        A real example of this? If you're making a static call in C to a function, the compiler can go look at the function and do this analysis. If you're calling through a pointer, a common operation (at least, I can't stand using C without it...), it can't, because that pointer could be pointing at anything, up to and including a dynamically constructed function (if you're brave). To maintain its promises to the programmer that a function call never changes the variables in the caller (which may be located in registers), it has to protect all the registers.

        Aliasing is a nasty problem because it's completely opaque to the compiler; the compiler can't see through that indirect function call to the function beyond, not even in theory. As the page mentions, other techniques are being developed that don't involve that sort of opacity by working around aliasing, and the JIT compilers take a different, more dynamic tack that in theory lets them do this analysis dynamically. (The Transmeta processors can also do some of this stuff, which is one of the ways they can speed up code when they run it a lot; they can do this more expensive analysis and dynamically optimize the code.)

        • Aliasing, Fortran, C, and C++ (Score:5, Informative)

          by devphil ( 51341 ) on Tuesday September 16, 2003 @10:10PM (#6982423) Homepage


          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 [lysator.liu.se]." 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.

          • Yeah... I thought the CS community at large mostly knew about this.

            They do; my elaborations came from my compiler course. But there are a lot of people, both programmers who never took formal courses (and this is one of the examples of things that programmers very rarely learn on their own but can be very beneficial to know when you need to make that function go 20 times faster, and this is also why it's so hard to explain why a good education can still be helpful to all but the most dedicated self-learne
          • C's ancestor languages may have allowed aliasing as well, and DMR just decided to continue that; I don't actually know.

            C's ancestors were untyped, so I don't know if it would have been possible to prevent aliasing. At best you give hints when pointers were copied, and hope no one deref's anything else.

            C99 added the __restrict keyword to the language.

            It's restrict in C99. __restrict is a GNU C extension.
    • As far as "why is it still being used at all" comments, two words for you: no aliasing.

      If that's the only reason, then it should be relatively easy to get similar performance in C99 simply by adding restrict's all over the place, no?

  • Why doesn't someone make a Fortran to C++ converter and help everyone out of their misery?

  • It's "free software" not "free-ware". (Score:5, Informative)

    by jbn-o ( 555068 ) <mail@digitalcitizen.info> on Tuesday September 16, 2003 @08:40PM (#6981768) Homepage
    You might think that a free-ware compiler would be good for promoting the language.

    Haggle over the technical merit of g77 all you want, but free software is not the same as "free-ware" [gnu.org].

    • If it's free beer then it's freeware. Software that is gratis (free+ware). Since no one has to pay to get g77, it's freeware. I wish the FSF would stop trying to redefine the English language.

      • If it's free beer then it's freeware.

        I've never seen anyone refer to zero price beer as "freeware": "We're having a party and there will be chips, salsa, and freeware at every table" sounds confusing to me--will there be beer or computer software at every table? Perhaps you were referring to "Free as in beer"?

        Software that is gratis (free+ware). Since no one has to pay to get g77, it's freeware. I wish the FSF would stop trying to redefine the English language.
        --
        Open source, without that fishy smel

  • The extra "not" in that post made it almost impossible to understand since it gave the most important sentance the exact OPPOSITE meaning (although in poor english).

    took me a while to understand what the heck was going on there.

  • Let it go... (Score:4, Insightful)

    by AJWM ( 19027 ) on Tuesday September 16, 2003 @09:00PM (#6981914) Homepage
    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 ;-)
    • 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.

      "Any sufficiently-complicated C or Fortran program contains an ad-hoc, informally-specified bug-ridden slow implementation of half of Common Lisp."

      :-P
      • 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" ;-)

        • 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" ;-)

          Not really. Take P to be any program. As we know, most programs can be implemented with a variety of complexites, so we designate the complexity of a program as c, and P(c) is an implementation of P that has complexity c.

          Now, Greenspuns's 10th states that for any P, there exists a program L, such

  • It is open source. It doesn't work if you sit there and cry about it not working the way you want. It works great if you decide it doesn't work so you fix it yourself.

    I don't care how you fix it. You can write the code yourself, or you can hire someone to write the code for you.

  • Comment removed (Score:3, Informative)

    by account_deleted ( 4530225 ) * on Tuesday September 16, 2003 @09:16PM (#6982021)
    Comment removed based on user account deletion

    • The current standard is Fortran 95 which, as another poster pointed out, is currently being developed into g77.

      I am pretty sure that is not true. All of the g77 information I could find indicates that g77 is no longer being developed. There are two Fortran95 frontends to gcc out there: g95 [sourceforge.net] and gcc-g95 [sourceforge.net], but these really have nothing to do with g77.

  • So little logic from a programmer (Score:5, Insightful)

    by Crashmarik ( 635988 ) on Tuesday September 16, 2003 @09:27PM (#6982099)
    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".
    • How can anyone think that the free availability of a vital resource impedes the progress of anything ?

      Did you see much C++ code being written that took full advantage of the standard, and did not violate it in any way before GCC 3.0 was released? I certainly didn't. The two biggest C++ projects I can think of are KDE and Mozilla. KDE took work to get working with gcc 3.0. Mozilla's decision from the start was to only use a minimal subset of C++ to avoid compiler issues.

      Or how about this one... how many
    • How can anyone think that the free availability of a vital resource impedes the progress of anything ?

      Think "welfare."

    • If you wan't to know what's hurting fortran you might try readin Dijkstra's "Goto Considered Harmful."

      I don't know whether that's meant to be a criticism of Fortran as a language or merely the way in which it's used. I've never learned Fortran and therefore I've never read much Fortran code, so I can't say whether most Fortran programmers use too many Goto statements.

      Still, if we're all supposed to regard Dijkstra's essay as gospel, then why have language designers continued to add Goto statements to l

  • I think the real issue is that people see languages such as java, C, C++, .net, and newer languages as more exciting to program in and fortran is percieved as archaic. Also there is only a small market for fortran programmers. Many people probably think that fortran is dean, not because of the compiler, but because fortran is like pascal and cobal. Old languages! Personally when you look at the number of java / C# / VB .net jobs out there, would you really want to learn a language that has such a small
  • In my former life as a grad student in the sciences the lack of a free f90 compiler definately prevented adoption of GNU/Linux as an alternate/cheap platform. We had code that simply could not be compiled because g77 lacked features that are older than some people reading this post!

    The vendor compilers however had all the f90 options, which 'forced' us to pay for the expensive developer packages instead.

    At the time, the two extensions we needed (IIRC) were STRUCT and POINTER, which were on g77's to-do

  • I once considered writing real code in Fortran. It was a fairly limited library of functions that were supposed to do heavy computations. Other parts of my program was to be written in C.

    When realising that G77 lacked many features that my documentation said I should find in Fortran 77 I gave up and wrote everything in C.

    Not blaming anyone, I was still a bit disappointed. The feature I lacked was the possibiliyt to pass structures as arguments to F77 functions.

    But of course, if G77 did not exist, I would

  • This is Depressing (Score:4, Interesting)

    by turgid ( 580780 ) on Wednesday September 17, 2003 @03:21AM (#6983797) Journal
    When I was doing Physics at Uni they forced me to use FORTRAN 77 for "portability" despite the fact that I already knew C.

    However, 10 years ago, FORTRAN compilers were very much more advanced in terms of optimisation for numerical work than C (e.g. the Cray compiler could do automatic vectorisation.)

    I would have thought that if you had a big, expensive supercomputer, you can afford the compiler. Not buying the compiler is silly, because you'll probably end up with an order of magnitude less performance out of it with a compiler whose primary goal is portability and has been designed to work well on totally different hardware architectures.

    Having said that, though, if you've got a low end box, you probably want a cheap or free compiler. Why spend $1000+ on a compiler when the box probably cost less? The low end box can probably sustain 100+MFLOPS (easily) and peak well into the GFLOPS. That's a cheap Athlon we're talking about. So you probably don't want to buy a fancy FORTRAN compiler. Why not just stick to C or even C++ nowadays? Legacy code :-(

    So you have a problem. The big supercomputer you bough 5 years ago probably has a "slow" C/C++ compiler. The nice cheap box you have on your desk has arubbishy FORTRAN compiler and a reasonable C/C++ compiler.

    So, you can convert all your legacy code to C and C++, you can buy a commercial FORTRAN compiler or why don't you universities cough up some time and money to give to the GNU FORTRAN people to help them improve their compiler? Or is that too radical and lefty?

  • what about the intel compiler ? (Score:4, Informative)

    by dario_moreno ( 263767 ) on Wednesday September 17, 2003 @05:07AM (#6984111) Journal

    The Intel Fortran compiler supports F90, dynamical allocation, works better than Absoft or Portland Fortran, and is free for Linux...and for all of you complaining about Fortran, do you have a job ? I know someone who ended with a very nice job just because he had mentioned "Fortran" on his resume, and had spent maybe 1 week of work on " Numerical Recipes in Fortran" and the Intel/g77 compiler.

  • In other news (Score:5, Insightful)

    by Chelloveck ( 14643 ) on Wednesday September 17, 2003 @06:26AM (#6984311)
    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.

    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?

  • Wrong conclusion (Score:2, Insightful)

    by Anonymous Coward
    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.
  • Is there still an important reason to program in Fortran?

    You can easily link modules of different languages. Why do you still work with a language which was long time obsolete when punch cards went out of fashion?

    I mean, of course you can bloat the language with structures it originally didn't dream of, but you can't expect every compiler author implement the newest expansion, for free. Just because he wrote parts of an existing compiler years ago.

    I'd say, like the old saying, if you don't find a softwar

    • My answer: Why not?

      If you know the language and the language can do what you want to do, then why not?

      Another good reason is if you are supporting existing software you might want to keep the code consistent.

      I'm not sure you can claim obsolescence for Fortran, especially at the time when punch cards went out (mid- to late-70's). The gold standard, F77, was used everywhere, and it remained the gold standard at least until F90 came out. While C was being used for taking care of OS issues (networking,

  • what is killing fortran (Score:4, Interesting)

    by Mark Muller ( 708201 ) on Wednesday September 17, 2003 @09:49AM (#6985634)
    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.
    • 1) clean, neat code that is easy to read by non-programmers.

      *snort* I'll believe that when I see it.

      2) Array bounds checking by the compiler - try that with C++. Array bounds checking saves me huge amounts of time in development.

      I use the STL and not think about bounds ever again.

      3) Compiler checking of function calls, via encapsulation of functions in modules.

      Unless you're badly describing another feature, that was one of the first features of C++ and ANSI C.

      4) Easy use of BLAS and LAPACK routi

      • Computer "sceintist" != Real Sceintist (Score:4, Informative)

        by goombah99 ( 560566 ) on Thursday September 18, 2003 @02:36PM (#6997215)
        Numerical recipies said it best. Scientist solve next years problems on last years computer. Computer "scientists" solve last years computer problem on next years computer. You appear to have no clue that all your statements about will slow the code and the memory management ot a crawl.

        1) clean, neat code that is easy to read by non-programmers.

        >*snort* I'll believe that when I see it.

        double snort. Did you know its not possible to make a typo type syntax error in fortran 77 that will compile? hard to believe I know but its true. ( You cant misplace a plus sign or comma or leave off a [] and have it compile.
        when I try to debug faulty c-code and see something like
        i = --j
        I have to try to figure out if they could have meant to write
        i = -j or i = j-- or i = --j
        yuck.

        2) Array bounds checking by the compiler - try that with C++. Array bounds checking saves me huge amounts of time in development.

        I use the STL and not think about bounds ever again.

        SLOOOOW. And unparallelizable. and it kills multi-processing dead. and loss of control over memory management. loss of memory mapped sub arrays, strides etc.... Sure you can do strides in c++ but now they are function calls not direct-to-memory. In fortran you can often pull contionals outside of loops using the WHERE syntax. Its much better to have a good syntax in the language than make up for it with a bunch of function calls and object instantiation. e.g. both languages can write
        A = B*C where A,B and C are matricies but C has to do it with objects and overloads. fortran does not. which do you think is going to be faster.

        3) Compiler checking of function calls, via encapsulation of functions in modules.

        Unless you're badly describing another feature, that was one of the first features of C++ and ANSI C.

        So fortran steals a good thing from C and you complain? In fact fortran 95 implemented headers much better than the asanine way C does it. If fortran you can declare the headers for the called functions right in the code that will call the function so fewere prototype mismatches occur. and fortran also lets you specify the not just the type defs but also whether the subroutine will change the arguments or not (without having to pass by value or declate things final). Thus the compiler can know for example if a cache will need to be written back or how to share memeory between two processors. or if it can multi-thread past a subroutine call.

        4) Easy use of BLAS and LAPACK routines for real computational work.

        >Two words: C wrapper.

        whoopee. I can say it in reverse: take the STL and put a fortran wrapper on it. now fortran has the STL.

        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!

        >Some argue that having a separate prototype prevents the implementor from arbitrarily changing the interface without warning their other team member.
        well fortran90 can either derive its prototype or you can specify them your call. its nice to have it both ways and not pay any price.

        >Fortran isn't perfect (yet). It still lacks the ability to make a function part of a data
        structure (ie, classes).
        not really true. You can program in an object oriented fashion if you wish. but its more like perl-objects where the data is explicitly passed rahter than C where its hidden from the user.
        in C++ you would say

        myobject->hash_get(key)
        in fortran you would say:
        hash_get(myObjectStructure, key)

        is there any important difference?
        It current i/o abilities still suck. It's ability to handle characters and
        character strings is terrible.
        Well fortran90 does have nice string handling. and of course it lacks the C string terminator problems that account for so many buffer overflow issues. But I w

        • Did you know its not possible to make a typo type syntax error in fortran 77 that will compile?

          Did it many, many times in F77.

          SLOOOOW. And unparallelizable. and it kills multi-processing dead. and loss of control over memory management. loss of memory mapped sub arrays, strides etc.... Sure you can do strides in c++ but now they are function calls not direct-to-memory.

          Real Scientist != Computer Scientist. What C++ compiler are you using? Even VC++ makes those calls in-line and optimized the heck

  • Is this really a bad thing? (Score:3, Insightful)

    by yandros ( 38911 ) on Wednesday September 17, 2003 @01:20PM (#6987542) Homepage
    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 frea
  • I was looking at the state of development of the FORTRAN compiler in gcc today and found this project to implement a more modern GNU FORTRAN compiler. It looks like it's a proper cross-platform complier, using gcc's back end for code generation.

Slashdot Top Deals

Almost anything derogatory you could say about today's software design would be accurate. -- K.E. Iverson

Close