Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Programming IT Technology

Is FORTRAN Still Kicking? 745

Algorithm wrangler queries: "I'm beginning to wonder if I should invest the time in learning FORTRAN. Although it is, arcane it seems to be the best tool when it comes to demanding optimization tasks and heavy computations. C/C++ does not cut it for me - it is simply too easy to make mistakes and I find myself using half of my time hunting bugs unrelated to the problem at hand. Additionally, although tools like Matlab exist they don't provide the power that justify the huge price tag they carry. I find any script based language (Matlab, Numeric Python, Scilab) to be inadequate as soon as it is necessary to use loops to describe a problem and using such tools for recursive systems can be a real pain. As another data-point, the Netlib repository seems to be very FORTRAN oriented, and it is a true gold mine when it comes to free routines for solving almost any computing task. What bothers me though is that FORTRAN code is really ugly and the language lacks almost any modern day language feature (I know about Fortran 90 but it is not much nicer than F77, and no one seems to use it). Can it really be true that the best tool we have for heavy duty computing is a 25 year old language, or have you found anything better - free or non-free?"
This discussion has been archived. No new comments can be posted.

Is FORTRAN Still Kicking?

Comments Filter:
  • Yes (Score:2, Informative)

    by mfos.org ( 471768 )
    FORTRAN is used in high performance scientific computing. The language allows for high parrelelization.
    • Re:Yes (Score:5, Informative)

      by Chundra ( 189402 ) on Wednesday August 07, 2002 @04:06PM (#4027552)
      "FORTRAN: "The infantile disorder", by now nearly twenty years old, is hopelessly inadequate for whatever computer application you have in mind today: it is now too clumsy, too risky, and too expensive to use." (1982).

      "In the good old days physicists repeated each others experiments, just to be sure. Today, they stick to FORTRAN, so that they can share each others programs. And bugs."

      --Edsger Dijkstra
      (Interestingly enough, Dijkstra died today.)

      • Edsger Dijkstra (Interestingly enough, Dijkstra died today.)

        Yeah, I saw that. Sad, losing a luminary like that.

        And pointedly relevent to this discussion, since FORTRAN used to use GOTO statements for branching.

        If you're considering FORTRAN, then beware the GOTO as Edsger pointed out in this classic. [acm.org]

      • Re:Yes (Score:4, Insightful)

        by joto ( 134244 ) on Wednesday August 07, 2002 @05:48PM (#4028612)
        Is there any language Dijkstra actually liked? I quote:

        PL/I, "the fatal disease", belongs more to the problem set than to the solution set.

        The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offence.

        APL is a mistake, carried through to perfection. It is the language of the future for programming techniques of the past: it creates a new generation of coding bums.

        It is practically impossible to teach good programming style to students that have had prior exposure to BASIC; as potential programmers they are mentally mutilated beyond hope of regeneration.

        Well, I think I might have heard somewhere that he actually said something nice about Algol, but I can't find a quote anywhere.

        Anyway, I wouldn't bother too much about what Dijkstra said 10-20 years ago about programming languages long dead. Both FORTRAN, COBOL and PL/1 has clearly proven themselves useful in numerous real-world applications. And contemporary Basic, like Visual Basic shares almost nothing but the name with the kind of BASIC Dijkstra was talking about.

        Of course, being a computer scientist, I certainly agree with him, but even I am not doing what I preach. C++ is certainly a large pile of shit, and C isn't much better. Java could almost make it, if it wasn't already so braindamaged by the C/C++ infection. Perl is certainly an offense to anyones aestethics (if people have that these days). Python could almost have made it if it weren't for the completely braindamaged scoping rules, and various other twarts.

        Well, guess what languages I use at my workplace? Do I violently disagree? No, because these are the languages that actually do the job, they have fine implementations you can trust, they have lots of available libraries for almost any task, and most people already know them, meaning anyone can pick up where the last person left.

        I am not a numeric analyst, so I've never had the use for Fortran, but if that was what I was mostly doing, I would certainly learn it. Learning to speak the lingua franca of numerical analysis will certainly be helpful if that's what you are going to do, even if you don't intend to use it yourself (but you will, trust me - I use C myself for the same reason). And I highly doubt that Fortran 9x is not much nicer than FORTRAN or Fortran 77, numerical people doesn't seem stupid to me, and certainly not as stupid that they would have invented it otherwise.

        • Re:Yes (Score:3, Insightful)

          by mjprobst ( 95305 )
          Keep your eyes on the progression of Python. They haven't fixed all the braindead scoping rules, but there appears to be an underground movement to move them towards something remotely more sane. Lots of work being done on Python between 2.0 and 2.2 . . .
    • Re:Yes (Score:5, Informative)

      by prefect42 ( 141309 ) on Wednesday August 07, 2002 @04:14PM (#4027647)
      This shows absolutely no understanding of the language. Sit down if you're not in the field.

      I used to teach "Practical Parallel Programminh" at the Univesity of Leeds and this is just crap. Fortran is typically used with OpenMP / MPI to do parallel programming. Older freaks might use PVM. They're all available for C/C++.

      And it's not that I'm no longer in the field, I currently work on Grid/Globus applications.

      Fortran is no more safe or fast to program in I'd argue it's a less safe myself. The performance difference between an optimal fortran program and an optimal C program I'd argue is nearly nil. Show me different, and explain why. Go on, try it.

      jh
      • Re:Yes (Score:3, Insightful)

        (My apologies for the repost... wasn't logged in... argh!)

        The performance difference between an optimal fortran program and an optimal C program I'd argue is nearly nil. Show me different, and explain why. Go on, try it.

        Pointer aliasing.

        The effort required to generate the "optimal" C/C++ program working with matrices or greater multidimensional arrays is nontrivially higher than the effort needed in FORTRAN.

        Look, I'm not pro-FORTRAN. But credit where credit's due, people. C/C++ compilers worry about things that FORTRAN compilers don't, mostly because of the semantics of multidimensional arrays in each language (one should say the lack of multidimensional array semantics in C/C++). Why do you think Blitz is such a hit? Why do you think so many compilers have all sorts of non-standard ways of letting the user indicate that there's no aliasing on a given pointer in memory (remember noalias? what about those ugly restrict and unlikely_alias hacks?)?

        You can make your number-crunching C/C++ code as fast as the FORTRAN folks' code, but it typically requires knowing more about your language tools than the aforementioned FORTRAN programmer worries about.

        So, give them the nod on this one. You've got them beat on any number of other fronts.
    • Re:Yes (Score:5, Interesting)

      by Rasta Prefect ( 250915 ) on Wednesday August 07, 2002 @04:15PM (#4027658)
      FORTRAN is used in high performance scientific computing. The language allows for high parrelelization.

      This is sort of true. Fortran isn't nessecarily all that much more inherently parallelizable than other languages, but because it is the language of scientific computing quite a bit of effort has been expended on compilers that automatically parallelize for vector computers. For non vector computers, it really doesn't matter what language you use - You'll be using MPI to do it anyway, so as long as you have a set of language bindings, you're ok. (Although as far as I can tell these only exist for C and Fortran...)

      The real reason that FORTRAN continues to persist in scientific computing is twofold - First, there is a huge Fortran code base. Both in terms of things like Numerical Recipies and completed code. For example, I spent my summer integrating a Weather Model with a fluid dynamics model. The Weather Model, MM5 decends from the early 1970's (Pre FORTRAN 77). It's in Fortran. It's large. It would take a hell of a lot of effort to rewrite it, and nobody is going to do it. Theres a quite a bit of this stuff around, and the effort to rewrite it would enourmous, and frankly not worth it.

      Second, most people programming in scientific computing are not CompSci's. They Computaional Chemists, and Electrical Engineers and Meteorologists and who knows what else - but not programmers. They learned FORTRAN and as long as they can get their stuff done in FORTRAN, they're not gonna learn C so they can track down a segfault when their pointers wander off an array. The new PhD's probably learned C and will use it if starting from scratch(After all, even in FORTRAN 90 Dynamic allocation and pointers are really, really limited, often requiring recompiles whne your problem size changes), but 40-50 year old computational chemists are not gonna learn C. Period. So FORTRAN continues to get upgraded. At least they got rid of the @#$% Hollerith-punch card column layout...

    • Fortran does not force you to write spaghetti code, any more than c forces you to generate buffer overflows or perl forces you to write unreadable code.

      Design and structure your application.

      If you are used to objects and methods, just use subroutine modules and entry points to the same effect.

      Fortran was where I learned to use multiple entry points into one sequential file for recursive processing.
  • Use Fortran 90 (Score:5, Informative)

    by Lally Singh ( 3427 ) on Wednesday August 07, 2002 @03:41PM (#4027289) Journal
    Fortran 90 has plenty of structured programming features to make maintainable code. Equally, if not more important, is that Fortran code can be much better optimized than C/C++ code for numerics. IBM did a good job on Fortran, and it's still a major player today.
    • Re:Use Fortran 90 (Score:3, Informative)

      by rsilva ( 128737 )
      Yes, I completely agree. I have already posted a message about this in Slashdot foruns where I described some of the Fortran 95 characteristics:

      http://slashdot.org/comments.pl?sid=3041&cid=145 39 90

      Something that changed from that time is that now we have a free compiler for non-commercial use (linux, i386):

      http://www.intel.com/software/products/compilers /f 60l/noncom.htm
    • by Tim ( 686 ) <timr @ a l u m n i .washington.edu> on Wednesday August 07, 2002 @04:02PM (#4027505) Homepage
      Don't use Fortran 90. It's as messy a language as C++, with the significant disadvantage that it has a much smaller user base.

      Honestly, your objection to C++ is unclear to me...you say you spend more time fixing bugs than approaching the task at hand? Is this because you don't know the language that well? Perhaps because you're not taking advantage of the many excellent libraries available to you? Keep in mind that C++ library design requires a great deal of skill, but using a well-designed library is actually easier than coding in other languages.

      C++ is my own personal choice for anything by the most demanding of high-performance computing applications. Is there an overhead to the language? Debatably, yes. Does it matter, in 99.9% of applications? No. And with only a little bit of forethought, even the "inherent" performance hits can be avoided in the places where it matters. It's just that you have to rely on a profiler to tell you where those places are...

      There is a significant community of researchers and developers working on scientific and high-performance computing in C++. Check out some of these:

      • POOMA [lanl.gov] - a high-performance mathematics C++ framework
      • Blitz++ [oonumerics.org] - a C++ mathematics library which uses template metaprogramming to achieve FORTRAN-caliber performance.
      • MTL [iu.edu] - another example of template metaprogramming.
      • oonumerics.org [oonumerics.org] - a good site for information on high-performance object-oriented code.


      These are just a few good starting points. Do a google search for 'high performance c++' to find many more. Just, please, for the love of Deity, don't code in FORTRAN. ick....

    • Re:Use Fortran 90 (Score:5, Informative)

      by L0C0loco ( 320848 ) on Wednesday August 07, 2002 @04:15PM (#4027665) Homepage
      Here at NASA we still use fortran (F90) for our processing of satellite remote sensing data. For brute strength and optimized speed it is hard to beat. F90 makes the code easier to work with. I like to use the AbSoft F90 compiler on my linux cluster. There are only a few differences from the DEC (HP - Compaq - whatever) fortran for thier Unix and Digital Fortran for Windoze. Using some good F90 rules adherance tools to keep you from including propriatary extensions smooths the process of assuring portable code.

      If you need to develop number crunching code that has a limited lifetime (disposable code) you might consider RSI's Interactive Data Language. This IDL is wonderful for developing code fast and is very powerful with its built-in graphics. It is also vector/matrix oriented and few loops are really necessary once you get used to the language. Bad part about IDL is the cost unless you can qualify for the student version ($75 last time I checked). Best part is that is comes with an extensive library of high level functions.
      Check it out at http://www.rsinc.com/ .

      Enjoy! Z
  • Yes, FORTRAN is still alive, and many important scientific applications are still written in it and maintained in it.

    Alas, for the rest of the question, I'm not a mathematician/number cruncher. The only floating point numbers I deal with are currency...
    • Mod parent +1 funny?

      You really, really don't want to use floating point for currency values. Eventually the logarithmic nature of floating point data formats [inet-one.com] will cause your calculations to be just a penny or two off.

      Much better to use a BCDish class or dedicated decimal type, depending on your programming language. Worst case, do all your calculations in the smallest unit possible, e.g. cents in the US.

  • FORTRAN was one of the first languages that I learned and although I don't use it much now it still has a special place in my heart. I always found its simplicity and structure sort of comforting.

    I'm a Java convert now thought.

    • FORTRAN was one of the first languages that I learned and although I don't use it much now it still has a special place in my heart. I always found its simplicity and structure sort of comforting.

      I always liked how I could define variables on the fly anywhere in the code. Really catered to my total lack of organization and self-discipline. I can do that in Perl, now, too!

    • by Subcarrier ( 262294 ) on Wednesday August 07, 2002 @04:02PM (#4027509)
      FORTRAN has the same kind of cherubic appeal as a very very large hirsute man wearing a tutu.

      You can leave FORTRAN behind, but you can never forget it. Sometimes, I wake up at night, thinking about it -- wishing I didn't.
  • NOAA (Score:4, Insightful)

    by OpenSourceRulez ( 183923 ) on Wednesday August 07, 2002 @03:43PM (#4027302)
    As a recent CS grad I had to help some of my friends in the Meteorology department with their programming course(of course not taught by a CS prof). To my surprise it was FOTRAN. It seems a lot of the stuff NOAA and other government agenicies program is in FORTRAN so it is compatible with the stuff they stil use from the 70's and 80's.
    • Re:NOAA (Score:5, Informative)

      by GuidoDEV ( 57554 ) on Wednesday August 07, 2002 @03:55PM (#4027416)
      Speaking of meteorological programming, ALL the major atmospheric models are written in FORTRAN. The ETA, AVN, NGM, MM5, WRF, and scores of lesser-known models...all of them written in FORTRAN (most of them FORTRAN-90 now, but some of the older ones are FORTRAN-77). The MM5 & WRF may be found here [ucar.edu] and here [ucar.edu]. The source code to several others is readily available as well if you're so inclined, for instance the ETA [noaa.gov] and the ARPS [ou.edu]. Anyone wanting to run them may do so fairly easily on a PC running Linux (any new PC will be able to run a fairly hi-res model real-time); I do so myself.
    • Re:NOAA (Score:3, Informative)

      by Jandar0 ( 594961 )
      Well, I can't speak for other agencies, but here at NASA Glenn Fortran is very much alive. A huge amount of the thermodynamic cycle/turbomachinery analysis that gets done around here is done using legacy Fortran code. Though they are no longer developing new codes in Fortran (at least in my office), it still lives. Rather than rewriting Fortran code, the effort (mine anyways) currently goes into writing generic GUIs for Windows to interface with those programs.
  • my dad is a physicist. he, and every colleague of his who writes code, writes it in Fortran.

    part of it is that there's 40 years of perfectly good legacy code to keep using. but mostly it's that C's numerical libraries still, after all this time, aren't as fast as a good Fortran's.
    • C's libraries may not be (and may never be due to compiler pointer aliasing issues), but C++'s are. One in particular is Blitz++ [oonumerics.org].

      Not to take away from Fortran. Language in general means far less to performance than an experienced programmer and good algorithms.
    • part of it is that there's 40 years of perfectly good legacy code to keep using. but mostly it's that C's numerical libraries still, after all this time, aren't as fast as a good Fortran's.

      I used to accept this as a good argument but I'm starting to question it. C has been around long enough that it's math libraries shouldn't be lacking. What's wrong? Why haven't the C libraries caught up to speed? Are you talking about proprietary libraries or the basic libm.so?

      • C has been around long enough that it's math libraries shouldn't be lacking. What's wrong? Why haven't the C libraries caught up to speed? Are you talking about proprietary libraries or the basic libm.so?

        We're not talking about sin, cos and the other stuff from the C library. We're talking about vector calculations and the like. The reason why Fortran's libraries are better are several fold. First, Fortran's still older; the stable Fortran 77 standard predates the stable C89 standard by ten years. Secondly, all the physicists and engineers are trained only in Fortran, so that's what they use, and when people need to speed up numeric code, that's what they optimize.

        Lastly, the Fortran standard dictates that any two arrays passed to a function do not alias - if they do, it's a error in the program. Since C compilers can't make that assumption, there's points where a Fortran compiler can rearrange actions for greater speed that a C compiler can't.
      • There are some fundamental weaknesses in the C language that make it less-than-optimal for writing numerical codes.

        1) C arrays are nothing more than pointers in drag. "Aliasing" of multiple pointers pointing into the same region of memory can cause optimizations to introduce bugs. Because all array accesses are done as if by pointer arithmetic, it is hard to deal with multi-dimensional arrays where more than one dimension can vary (think rectangular MxN matrices). There is a bias in the language toward manual pointer movement (*p++, etc.) to efficiently stride through arrays.

        2) C always "wants" to compute with doubles. (E.g. the usual trig libraries all return doubles, and the default function call rules cast float arguments to doubles.) Serious number crunching code may want to use single precision floats to conserve memory and, more importantly these days, cache and memory bandwidth.

        3) No built-in exponentiation operator. (Important so that the compiler can optimize small integer powers as combinations of multiplications.) No built-in, transparent complex number support. E.g. trig functions with complex arguments.
  • FORTRAN is easy (Score:2, Informative)

    by Philippe ( 3665 )
    You can become a passable FORTRAN programmer in a couple of hours if you already know another language, such as C or Pascal. There are a couple of gotchas (predeclared variables & COMMON statements IMHO).

    If you are going to touch any heavy simulation code (such as statistics, physics & biology) learn FORTRAN. It works very well for those problems. Yes, it is old, but that doesn't mean it's bad. It's not modern, but it works surprisingly well.

    I find myself teaching FORTRAN to budding scientists, and they are able to write complex stuff very quickly because they don't trip all over the language (e.g. '==' vs '=' in C).
  • by drudd ( 43032 ) on Wednesday August 07, 2002 @03:46PM (#4027327)
    Fortran has several things going for it...

    1) it's been the standard scientific computing language for so long, that every platform has a compiler, and that compiler is likely to be very mature (i.e. stable, and produces fast code).

    2) since it's been a standard for so long, everyone has routines written in it which have been debugged and work, no sense rewriting them and introducing errors.

    3) the language itself lacks complicated constructs, so it is very simple to optimize. This, with (1) makes fortran still outperform c, thanks to the compilers.

    That said, I HATE fortran with a passion, mostly because it's ugly. 6 character variable names are impossible to deal with. Couple this with capitalization and indentation rules left over from the punch card era and you have code which is literally painful to read.

    Doug
    • by Tim ( 686 ) <timr @ a l u m n i .washington.edu> on Wednesday August 07, 2002 @04:35PM (#4027865) Homepage
      While the first two of the three points listed in the parent post are somewhat true, they are usually mitigated, depending on the languages you consider (e.g., you can find good compilers and well-optimized routines for C++ that will perform on par with FORTRAN, but maybe you can't for, say, Java).

      However, the third point is actually a disadvantage in my mind: the overwhelming simplicity to FORTRAN leads to simple-minded implementations that are often less efficient (in time and especially in space) than a good implementation in a more modern language.

      Case in point: Check out the sorting chapter of Numerical Recipes, and you'll find that their "ultimate" sorting algorithm -- and hence the algorithm that a whole generation of FORTRAN coders think is the fastest -- is heapsort. Now, heapsort is a fine algorithm, but it has some significant disadvantages over quicksort (the algorithm used in the C/C++ standard library. well, almost, anyway.) Of course, you can't implement quicksort properly in FORTRAN because the language isn't recursive! So, I guess it makes sense that they skip over it in Numerical Recipes.

      These sorts of issues abound in FORTRAN programming. A lot of (older) engineers and scientists still insist that FORTRAN is the best language for high-performance mathematics, and to some extent, they're correct. As long as your mathematics are limited to those problems that can be solved with gobs of iteration, FORTRAN is your tool. But the minute you step into a realm where a more advanced data structure would be more important to performance (think hashes, heaps, trees, linked lists, etc. Places where algorithms actually matter.), FORTRAN falls flat on it's face. And don't even get started on space efficiency -- any modern language will beat FORTRAN 77 on this, hands down. Pre-allocation of arrays tends to kill an application's memory footprint...

      Some of these issues are addressed in FORTRAN 90, but really, if you're going to use that language, you might as well use a language like C++, which is more common, and just as efficient, with proper care.
    • by jjtime4sko ( 321416 ) on Wednesday August 07, 2002 @04:53PM (#4028033)
      I'm not going to wade in on a lame language war, but Fortran IS very portable. I have worked on code that was written in 1967 for a CDC mainframe. It was then ported to a:
      PDP-11, then a
      Vax, then a
      486-class PC. The code ran much faster on the PC then the Vax.

      Then I discovered that I needed a routine from the original CDC implementation, which had not been touched since. So I typed in the routine FROM CDC PUNCH CARDS. Compiled perfectly.
  • I know of a lot of research and development facilities that still use fortran for mathematical modelling, and mathematical programming. Especially mathematical modelling of physical phenomena (ie. nuclear power plants, etc.)

    I didn't find it that hard of a language and I believe it would be worth learning for someone who needs to mathematics on a computer simply and easily without having all of the dongles and doo-dads. :-)
  • to your C code. You just have to know how FORTRAN arrays are held in memory and how long the FORTRAN types are. Then you need to know what standard FORTRAN libs you need to link, so that your numerical libs will work. I did that for lots of my numerical work and it worked fine. You have to test it of course and it takes a while to work out the kinks.
  • What are these modern language features you are looking for?

    FORTRAN is almost perfect for what it is used for: massive number crunching. Very little bells and whistles, which allows the programmer to concentrate on the numerics of the problem at hand and not the picky little programming details.
    • What features? How about things to make number crunching easier.

      In C++ I can extend the existing functions (such as sin(), exp(), operator+()) to support infinitesimals as well as ordinary floats or doubles. Using that I can automatically differentiate functions written in C++ making it trivial to code things like 2nd order optimisation routines. Try the same in FORTRAN. The nearest thing I can find anyone doing is using preprocessors that differentiate your source code line by line. (1) it's hideous and (2) well it's hardly still FORTRAN if you have to preprocess your code.

      Using C++ it becomes trivial to write code to compute second derivatives in applications where the textbooks say things like "traditionally we make do with first order approximations because evaluation of second order computations are complex to implement". Of course they're hard to evaluate if your ideas of how to program come from the 1960s.

  • by IPFreely ( 47576 ) <mark@mwiley.org> on Wednesday August 07, 2002 @03:49PM (#4027366) Homepage Journal
    ... 20 years ago, (ye gads). It is OK, but not anything special. About the only special feature it has is the builtin COMPLEX type. Beyond that, you're in just another procedural language, and an old one at that.

    The problems you described in C/C++ are probably mostly inherant to C. C is not type strict, so it lets you shoot yourself in the foot (or head) a lot.

    What it sounds like you want is a strongly typed and type safe language. That would catch most of your problems, assuming your're just writing algorithms and not trying to interface to strange API or hardware.

    PASCAL/MODULA-2/-3, or ADA can probably do what you want, and have GCC frontends available. These languages usually have runtime checks for safety, but after debugging, you can usually optomize them out for a production release.

    So over all, go compiled, go type safe, go modern/OO if you can.

  • by teamhasnoi ( 554944 ) <[moc.oohay] [ta] [ionsahmaet]> on Wednesday August 07, 2002 @03:51PM (#4027374) Journal
    Why? You ask?

    Approximately 8000 years from now, when the date flips on December 31, 9999, I predict widespread panic and failure of computer systems all over the world. Since these 8040± year old systems will run on FORTRAN, it is imperitive that we all learn FORTRAN and teach it to our children. This oral tradition will save the human race when these systems fail to roll over the date on December 31, 9999.

    You must act now! Only YOU can prevent Y10K!

  • by Deagol ( 323173 ) on Wednesday August 07, 2002 @03:51PM (#4027381) Homepage
    I work for a High Performance Computing center at the university which employs me. A good percentage of the code people write (or acquire and maintain from some government project) is FORTRAN. There are compilers for every major OS we support, and they are used.

    Saddly, there's no GNU (or other Free) FORTRAN 90 compiler that competes well (or at all) with the commercial ones.

  • I use Fortran 90. That is, I port Fortran 90.

    My beef with Fortran 90 is that it is very unportable. Every compiler follows the standard to some extent, and then has its own extensions. Many, but not all, support some obsolescent Fortran 77 syntax. Your best bet, if you want to achieve portability, is to use Intel's Fortran 90 compiler; it is the strictest.

    As for Fortran 90's use, it is used very much by scientific and mathematical types who do parallel programming. I'm working this summer at a ``high-performance computing'' lab, and of three scientific applications I've looked at, all three have been written in Fortran 90. I can understand why. Dynamic matrices are *so* much easier. But if you write or find a good C++ class for dynamic matrices, then you might not need Fotran 90.
  • by McDoobie ( 409584 ) on Wednesday August 07, 2002 @03:56PM (#4027423)
    Different languages have different strengths and weaknesses. I use Fortran, C, Ada95, and Ocaml interchangeably for different tasks. Often times linking the object files into a single executable.
    Fortran, designed for mathematics and engineering, obviously excels at that job. You might want to consider writing the "intensive" parts of your application in Fortran and then linking it with modules written in another language such as C or Ada.
    I've found that C is perfect for handling the I/O routines for such apps, but my Ada libs are ideal for doing memory managment and when the code outgrows the practical limitations imposed by Fortran.(Note: Interfaces.C and Interfaces.Fortran).
    Likewise Ocaml tends to fit around anything with a minimum of hassle.
    Of course, this is just a subjective evaluation derived from my own experiences. However I would encourage you to experiment to find the combination that works best for you. As we all should know "Theres more than one way to do it."

    I'm sorry if this post seems somewhat vague, but it would be rather hypocritical of me to outright prescribe a certain language or tool when I personally have a tendency to float around and use whatever tool is most convenient.

    NiCad
  • It will export your script as C.
    • It will export your script as C. ...and Java and Fortran.

      From the websites www.maplesoft.com and www.mapleapps.com:

      The new CodeGeneration package provides routines to translate "numeric" Maple procedures and code, such as expressions, lists, arrays, rtables, and lists of equations, to Java code. This new package also contains improved versions of codegen[C] and codegen[fortran]. You now have several options to choose from when translating Maple code to Java, C or Fortran code that provide greater control over how analysis and translation of types are performed. Maple 8 has extended the external linking capability with the ability to link to static Java methods.
  • by Wakko Warner ( 324 ) on Wednesday August 07, 2002 @03:58PM (#4027464) Homepage Journal
    Fortran is used HEAVILY in very specialized industries -- almost any mechanical design or scientific modelling program has some Fortran code in it.

    What do you want to do with it? Model fluid dynamics? Do structural or materials analysis? (Such software already exists.) Or do you simply want to find a better way to encode your DivX files?

    It appears to me as though you are trying to select the proper tool for driving nails into wood, while looking in the screwdriver section of the hardware store. If you need to ask why you should learn Fortran, you probably shouldn't learn it.

    - A.P.
  • A friend of mine is very much into computer simulations of physics and chemistry - he writes his own code in c / c++, and so manages to do on a (heavily optimized) Linux PC what his colleagues using FORTRAN still need Crays to run. All the difference is that he can use custom datastructures that FORTRAN (and the existing libraries) does not offer him.

  • If you need to do numerical linear algebra (vectors and matrix), nothing beats Matlab. But as you said, Matlab costs a bunch of money. Maybe you'd be interested in Octave [octave.org], an open-source, Matlab-like and mostly Matlab-compatible scripting language / interpreter.
  • My dad is a computational physicist. He works with some codes that are k*100,000 lines of FORTRAN. Mostly f77 too.

    Once upon a time, Cray had a really good automatically vectorizing compiler for FORTRAN and a mediocre C compiler. The Killer App stuck.

    The word on the street (from my dad) is that new physics codes are being written in C/C++. So, maybe in 20 years most of the old FORTRAN will be replaced.

    I've tried to get my dad to learn more C/C++, but he plans to retire before that's necessary.
  • I'm doing some consulting this summer for a company in my home town, and they have a VERY odd fortran implementation.

    It grew out of an old fortran (formatted type - probably f60 or so) program that was written by some guys in germany for calculating the size and price of heat exchangers. This company I work for has since decided it needed to have a web front end for this program and had a couple of engineers (this is the first problem - NEVER have plain vanilla engineers write code!) come up with a 'solution'.

    What they have now is a mess of ASP pages using VB dll's to call a Fortran 60/77/90 and C++ conglomerate program that ultimately writes ASP (yes! directly out of the fortran). All of this interfaces with multiple databases stored on both an AS400 and a Dell/Windows machine.

    IT IS A HUGE FREAKING MESS!! I was brought in to clean it up - and redo all the pricing. I have done what I can - but short of a total rewrite it is not going to get much better.

    Fortran needs to die a horrible death. It is soooooooooo ugly to look at and decipher (all of this code didn't even have branching statements in it - it just had a TON of GOTO's !!!).

    Just thought I would share my experience......

    Derek
  • by coult ( 200316 ) on Wednesday August 07, 2002 @04:03PM (#4027517)
    ...of the simple loop structures. In C, you can have a for( ; ; ) statement that does basically all sorts of weird crap in here ( ; ; ), and you can also do things like pointer aliasing (impossible in Fortran since there are no pointers at all).

    Fortran loops, on the other hand, are very very simple - all you can do is increment the loop variable, and repeat. That allows for very heavy loop optimization by the compiler - comparable to what the best assembly programmers might be able to do. Furthermore, a Fortran compiler can more easily generate optimized loop code using vector instruction sets like Altivec or SSE2, whereas C compilers have a much harder time (again, because of the wide variety of loop structures possible in C, and things like pointer aliasing, etc.)
  • by QuantumFTL ( 197300 ) on Wednesday August 07, 2002 @04:03PM (#4027524)
    It's obvious that the story's poster didn't really look into FORTRAN much past the aging F77.

    I currently use F77 to do research in magneto-hydrodynamics simulations of neutron stars on Cornell's Velocity Cluster (which has been featured on slashdot before). Fortran, due to its lack of things like pointers, etc, is rediculously efficient, and almost completely cross platform (because surprise surprise- it's very difficult to attempt to do anything remotely platform specific). The language is much simpler than something like C with pointers, etc, that must be messed with. Sure it's ugly as hell, but once again the newer versions of Fortran take care of most of these issues.

    I would suggest that anyone interested in high performance computing should check out High Performance Fortran [rice.edu]. It's a set of extensions to the F90 language to allow the seemless integration of large-scale parallelization in your code. It also has several other performance advancements.

    I highly disagree with the poster of the story, Fortran 90 is much more modern than F77, including things like objects, safe pointers, better recursion, better array sharing, generic routines (a type of function overloading). The language syntax is also much more lenient than F77 (which was designed to work with punchcards). It also has some really great array operations (things like slices, etc) that are rediculously fast. While I absolutely hate F77, if I was going to write a computationally intensive simulation, I'd probably do so in F90 or HPF.

    A lot of people still use Fortran, especially computational physicists and meteorologists... Many of these people don't have time to learn new programming languages, and Fortran works very well for what they need, better in most situations than almost any other language. It's something to consider.

    Cheers
    Justin
  • I work as a controls engineer at the NASA Ames Research Center. Most of the nonlinear aircraft simulations are still written in FORTRAN. FORTRAN provides very robust mathematical libraries while making it very easy to parse text files. In other words, FORTRAN is ver good at taking a text document of flight data, and crunching it into a useful simulation. The main thing is that so many compilers and languages talk to FORTRAN. I do a lot of work in Matlab and C, and both can link to my FORTRAN code. I can pull up an old simulator from the early 90s, slap on an s-function or C-wrapper, and use the code in my new code. Of course, the question is: is new FORTRAN code being generated for reasons OTHER than to be compatible with the old code, or because it is the only language the crusty engineer knows? Well, it's a toss-up. Matlab seems to be making a lot of headway, especially since it's code is very C-like and can link to old code. But, the gnu g77 compiler means I can distribute my FORTRAN work to anybody with a Unix box. Not everyone has put out the cash for Matlab. My recommendation is to learn enough FORTRAN to understand the math and logic loop functions. This will be enough to be able to read old code, and to be able to write math subroutines to be linked to more modern code. I still have to write in FORTRAN, but it's uncommon that I ever write a stand-alone FORTRAN program with an interface or anything. It is mostly text-file and math subroutines for Matlab or C.
  • Can it really be true that the best tool we have for heavy duty computing is a 25 year old language

    Can it really be true that the best tool we have for driving nails is a 3000 year old piece of wood with metal on the end?
  • matlab (Score:3, Informative)

    by SETY ( 46845 ) on Wednesday August 07, 2002 @04:04PM (#4027530)
    I don't use fortran and here is why.......
    There is Matlab www.matlab.com or the GPL version www.octave.org
    Matlab doesn't give arcane error messages. Matlab has piles of built in functions for every basic math thing you could want. Matlab has many toolboxe's etc etc. Almost every university has a Matlab license and companies can afford a license.

    Now the reason I am so pro-Matlab is it makes me much more productive for the simulations and experiments I run. Matlab is slower than raw compiled code (c,fortran,etc), but the productivity gains more than make up for it. If you are writing on fortran simulation that is going to run for a year on a super-computer don't use matlab. If you are writing many smaller simulations and ones that can use Matlabs tool-boxes than give it a shot.

    When Matlab is slow you can always write a bit of c or fortran code and put it in with the Matlab. I've done this for a few long simulations. Also have Matlab and Labview (www.ni.com) integrated is fantastic.

  • The language you use of course always depends on the context its used in.

    If you want something that is strongly typed and does recursion extremely well, I would recommend ML. Yeah its a bit funky if you've never used functional languages before, but its pretty damn powerful (I even wrote a compiler in it..) And its one of those languages that has almost been proved "safe".

    I, myself, have never used FORTRAN. I guess I've never happened on an occasion to use it, so I'm not that familiar with its optimizations. However, gcc optimizations are pretty damn good at producing assembly that is just about as fast as someone hand-coding the assembly. Also, Intel has some optimized libraries (I know they have some for Image Processing...not sure about general math...) so that might be something to look into. And I"m sure its possible to rewrite the FORTRAN libs in C (or something that provides an extremely easy interface).
  • by jvmatthe ( 116058 ) on Wednesday August 07, 2002 @04:04PM (#4027537) Homepage
    I'm teaching "scientific computing" for the second time at my university this fall and we're going to be using FORTRAN with some C (and C++ if that's your cup of tea). The department here is somewhat slanted towards FORTRAN and C instead of scripted environments and there is some outright dislike of Matlab. In this sense, FORTRAN was worth knowing around here and I had to brush up on my skills, since I'd not touched it since spring of 1992.

    The course mainly focusses on solving machine numbers, solving linear systems (direct and iterative methods), solving non-linear systems (mostly Newton-type methods), and solving eigenvalue/vector problems. The codes that students wrote last year started from scratch with early assignments. Then, I allowed them to incorporate Basic Linear Algebra Subprograms [netlib.org] (BLAS) into their codes. Then they were allowed to use LAPACK [netlib.org] for the rest of the semester. They were free to use the C interface, but most chose to use the FORTRAN examples, probably because of the skeleton code that I provided.

    Given the tremendous amount of code that is already out there, I agree that knowing FORTRAN is an asset. And since it's not hard to learn, why the heck not, right?

    On a side note, they had to use Makefiles, LaTeX their assignments, and send everything to me electronically in a gzipped tarball. They got quite a workout in console tools. For reference, I had some that were quite familiar with the system and some that had had BASIC at some level and that's it. Lots of help was needed as the semester reached the final weeks.

    Matlab was used for visualization and graph creation, but I am considering using GNUPlot this year, if it is up to the task. (I think it probably is.) I may also encourage the use of Octave [octave.org], where possible.

    For reference, the class website (which will soon be updated for the new semester) is here: Math 224 [duke.edu].

  • As many people have pointed out here - it can shift a serious number of uh, numbers.

    The language feels as though it's designed by a committee and has features tacked on left, right and centre. IO sucks arse, so don't expect to write a wonderful user interface for it (but you could always do a wrapper in another language, I suppose).

    I use F90 at uni, and although it's a bit of a messy language it does what it's good at: spewing out tables of numbers. It is expensive for a single licence, however. I wouldn't bother with it if I didn't have access to the university number crunchers.

  • Err, big deal (Score:3, Interesting)

    by Matthew Weigel ( 888 ) on Wednesday August 07, 2002 @04:07PM (#4027566) Homepage Journal

    All we have is this "25 year old" language for numeric tasks, and another language that's about as old for system programming. It's called C.

  • Fortran is truly ugly, if you need to write fortran, at least do it an ratfor (Rational Fortran) described by Kernigan and Plauger in Structured Programming [amazon.com].

    Ratfor adds "normal" structured programming constructs to fortran to make it readable by somebody less than 40 years old.

    You write code that looks like:
    for(i=1;i=100;i=i+1) {
    fortran code here
    }

    Ratfor generates:
    23002 if(.not.(i.le.100))goto 23004
    fortran code here
    goto 23002
    23004 continue

    I dont know about Linux, but ratfor is included in the FreeBSD ports.

  • C will be around for at least another fifty years in some form. Java will be around at least another twenty years.

    With enough production code, you can essentially push a language's lifespan out to infinity.

  • Try SciPy (Score:3, Interesting)

    by drklahn77 ( 599154 ) on Wednesday August 07, 2002 @04:10PM (#4027599) Homepage
    SciPy is an open source python application that sits on top of quite a few C and Fortran libraries. It is specifically targetted at the scientific computing community, and its performance is quite good, even though it's still a very young product. It supports massively parallel computation, has a number of nice plotting and graphing features, and is completely cross platform. It also includes weave, which allows you to produce native C code from python.

    Best of all, it's python, which means the learning curve isn't as punishing as C++, for instance.

    The website for SciPy is:

    http://www.scipy.org/
  • FORTRAN is still a useful language for engineering and scientific computing for several reasons.

    A very good one is that FORTRAN isolates the platform much better than C does. a real is a real is a real. At most, it's a matter of finding the appropriate compiler option.

    A great many people in the field know FORTRAN.

    Lack of issues such as pointer aliasing, etc, make automatic optomization and to an extent parallelization go much better in FORTRAN.

    C's history is one of letting the programmer optomize the code, FORTRAN has a stronger history of considering that the compiler's job (good for numerical programming).

    There's a lot of good, well used and tested code out there for FORTRAN.

    If your interests lie programming for scientific or engineering, especially HPC, FORTRAN is still a must.

  • by astroboy ( 1125 ) <ljdursi@gmail.com> on Wednesday August 07, 2002 @04:11PM (#4027612) Homepage
    FORTRAN is an extremely simple language; because of this, optimizers can go nuts, writing extremely tight code. If you're trying to do lots of intense number crunching, and performance is an issue, it really is the right way to go. FORTRAN 90 has some support for modular programming and gets rid of a lot of silly syntactic things which have been mentioned elsewhere (6-char variablenames, strict line formatting, etc.). That's why even Freshmeat [freshmeat.net] has 29 FORTRAN-related projects.

    Having said that, when you're writing a large piece of code, much of the code probably isn't number crunching; its schlepping data back and forth between solvers, doing I/O, etc. For that, FORTRAN is fairly limited; so you use other languages.

    You use the right tool for the part of the code you're writing. We are working on a large simulation code; our numerical solvers are all in FORTRAN, and we have no intention of chaning that; however, we use other things (C, Python) for higher-level tasks. And this is how it should be. People who argue about `Language X rocks!' or `Language Y sucks!' Just Dont Get It. All the languages still in use are still in use for a reason -- they have certain things they're good at. And so you pick the right tool for the job.

  • Back when I used to work in a University Maths department we used Fortran almost exclusively. Because its quicker and easier to code up most math problems in Fortran rather than C and because of the extensive numerical libraries available. The compiler we used would tell you off if you used swear words for your variable names. So of course our favourite game was looking for expletives that the compiler didn't know about. Some of them got pretty inventive!!
  • Perl has some handy features in this respect. It's a nice high-level language in its own right, and the Perl Data Language module (PDL) provides access to some very nice numerical and binary data libraries including some that are written in FORTRAN.

    I know Perl seems too high level at first, but give PDL a try. It's well worth the investment of time to get to know it.
  • by frank_adrian314159 ( 469671 ) on Wednesday August 07, 2002 @04:17PM (#4027681) Homepage
    ... but they knew what they were about. COBOL was about records and batch processing, Fortran and APL were about arrays and procedural programming, SNOBOL was for strings, and Lisp was about LISt Processing. These languages, although having expanded their paradigms, are still the best ones for doing those types of tasks. They (Lisp and COBOL, in particular) have seamlessly integrated more paradigms and are fully usable.

    Also, despite what you say, well formatted Fortran code is no more ugly than most other code (and a hell of a lot nicer looking than your average Perl code :-().

    I don't know why people believe that newer languages are automatically better. At the end of the day, you got storage, you got ops screwing around with the storage, and you got a mess of control flow holding the guts together. Just because I'm some hotshot wanting to get my name in the (geek-) papers with my shiny new syntax doesn't mean it's any different. And it certainly doesn't mean it's any better.

    So go ahead and learn Fortran. Learn about the joys of representing linked lists as a set of next indices into an array. Learn about dimension statements and equivalence blocks. Learn how to squeeze down your numeric processing into the nub of a kernel of procedural truth. You'll end up being a better programmer.

  • by FreeLinux ( 555387 ) on Wednesday August 07, 2002 @04:19PM (#4027706)
    I see these annoying questions all the time. "Don't tell me that a 30 year old whatever is the best we have!" Alright, I won't tell you. But, I'll tell everyone else, Fortran is sometimes the best language for the job, even after 30 years. It is simple, fast as hell and very robust. What's wrong with that? Oh, you can't write a gui in it or you can't have derived object classes? Tough, that's not what it was designed for.

    Why is it that the age of a language or tool is associated with it being inferior? Do you feel that everything that was created prior to your birth is inadequate or inferior? It is in fact, very common for the earliest versions of many things to be far superior to newer ones. This is true, not just for for languages but also for many other things. Most often, the "improvements" and "advances" that are made cheapen, dilute, complicate and destabilize the original product. This is, at least partly to blame for the disposable society that we live in today. Better, or smaller faster cheaper, usually also means less reliable and durable.

    To answer your question, yes. Fortran is still a very viable language and is still, after 30+ years, the best language for heavy number crunching. If you need to create a gui and have derived oject classes as well, just link to the fortran libs. But, I'm sure that some snot nosed whippersnapper will suggest that Perl is the only solution. Puhleez!

    • A quick search on jobserve [jobserve.com] turns up 19 current job listings requiring Fortran. Not bad for a 30+ year old language. Several satellite, stress engineering and meteorology jobs.

      Working code just doesn't stop working because some new language has come out. Imagine having the job of converting 5 million lines of fortran code into visual C++ dotNet code. By the end of the week. With no errors. And no overtime... It just doesn't happen, working code doesn't need to be replaced, and thus it isn't.

      I'm still surprised when recruiters ask me about my fortran and cobol skills. I don't list them as skills, because I haven't touched them in more than a decade. But the skillPimps can see I'm an old fart, and the older ones know I started my career with the old languages, because perl and C++ didn't exist in 1972. Hell, Larry Wall was still in diapers when I first touched a computer.

      This goes back to the discussion, here and other places, about the difference between coders and computer scientists. Coders insist the only language they know is the only one for the job, because they are too uneducated to understand a language is just a tool. CompSci gurus will just pick up the best tool for the job, whether something ancient like fortran, or something like a procedural language or even assembler.

      the AC
  • by 4of12 ( 97621 ) on Wednesday August 07, 2002 @04:20PM (#4027714) Homepage Journal

    I've known FORTRAN since...well...for longer than many slashdot readers have been alive. Done big, numerically intensive projects in it for many years in the 1980s.

    I've also done C (1990s) and C++ (2000s).

    Ten years ago the criticism about speed was true - that compiled FORTRAN would beat C++ to pieces. Not anymore, unless you're committing newbie mistakes in C++.

    If I were you I'd make the best of all worlds. I'd use Python for upper level logic in a clean syntax, in a quick scripting environment.

    Then, if there's numerically intensive loops in the lower reaches of your code that get executed billions of times, go ahead and use FORTRAN. Especially when you're doing something like computing eigenvalues for specially shaped matrices, etc., where chances are someone has already written a FORTRAN subroutien to do it well.

    Finally, use something like SIP or SWIG to connect the upper level Python to the lower level FORTRAN. Look, too, at Numerical Python and SciPy for others that have been down this road.

    There's a lot to be gained from all those netlib routines that have withstood the test of time and been optimized to such an extent that even the FORTRAN programmers surrender, and drop down to call BLAS routines that are best written in assembler.

    Using FORTRAN for the whole project is asking for pain once you start looking at things like parsing character input, connecting to network, linking into system libraries written in C. Been there, done that, have the scars.

  • Matlab? (Score:3, Insightful)

    by gcondon ( 45047 ) on Wednesday August 07, 2002 @04:32PM (#4027832)
    While I certainly agree with your observation that Matlab is pricey, I don't understand your complaint that it is "inadequate as soon as it is necessary to use loops to describe a problem".

    Heck, one of Matlab's greatest advantages is that every numeric variable is represented as a matrix and that many loops can be dispensed with completely with a little judicious linear algebra.

    If you want to rip on Matlab, you'd be better off scorning its poor memory management or its byzantine handle graphics.

    However, it does provide a nice development environment for computationally intensive problems. Scripting is a lot nicer than compile-link-debug-repeat when you're still trying to figure out the problem. Plus you can always farm out the most intensive processes to external code modules - which you can write in C/C++, Java or (gasp!) FORTRAN.

    If price is the sticking point - why not take a look at GNU Octave. It is free as in beer (not GPL despite the name) and offers much of the same functionality as Matlab. Unfortunately, it shares most of the weaknesses of Matlab as well - and they are usually worse.
  • Try O'Caml (Score:3, Informative)

    by Tom7 ( 102298 ) on Wednesday August 07, 2002 @04:53PM (#4028017) Homepage Journal
    Try O'Caml (caml.inria.fr [inria.fr]); it's a modern language that's compiled very efficiently (independent benchmarks [bagley.org]) and is suitable for heavy crunching. O'Caml has lots of features that you won't find in many languages, like algebraic data types, higher order functions, etc., but is intended for real general purpose programming. Most importantly, it's type-safe (statically) so you probably won't spend as much time tracking down bugs unrelated to the problem at hand. (That has certainly been my experience with SML, a language from the same family.)
  • by coats ( 1068 ) on Wednesday August 07, 2002 @05:41PM (#4028546) Homepage
    1. Fortran as a language has evolved over the years. Most of the complaints that I see here are really myths about 1960's vintage Fortran-IV, not even about quarter-century-old Fortran-77.

    2. Always use IMPLICIT NONE in your Fortran; making declaration of variables required (as this command does) really can save your butt on large programs.

    3. It is really nice to program in a language where arrays are true "first class citizens". In neither C nor C++ can one conveniently and efficiently do the equivalent of
      Subroutine S( M, N, P, A ) ! arguments: Integer M, N, P Real A( M*N, 13*P, M+N-P ) ! local variables: Real X( M*N, 13*P, M+N-P ) ...

    4. For the current generation of compilers, Fortran is about twice as optimizable as C or C++. There are a number of reasons for this:
      • C compilers generally lack the address-calculation optimizations required for efficient access to run-time-dimensioned multidimensional arrays (stubbornness of the C-compiler writers being an obstacle here ;-()
      • Aliasing (array-overlap) assumptions present in C and C++ but not in Fortran (this may eventually be fixed by strinct-ANSI typing rules and restrict pointers -- provided that the programmer is smart enough to use them correctly.)

    5. A native complex data type is nice to have for many applications domains.

    6. Fortran character-strings frankly are both safer and a lot easier to use than C strings: they're the equivalent of a system-supported
      struct{ int length; char * contents; } foo_string;
      together with built-in (and optimizable!) concatenation operators, and comparison operators that behave sanely for different-length strings.

    7. Fortran-77 and K&R C are "small" languages with simple concepts and therefore are easier to learn and understand. Fortran-90/95 and ANSI C89 are "large" languages with correspondingly more subtleties and difficulty of learning. C++ is a huge language, and almost impossible to learn and understand completely--a fact that has much to do with the popularity of Java.

    8. As a numerical analyst, I find the fact that C -- by explicit wording in the standard -- refuses to respect parentheses, and has ill-defined arithmetic to disqualify that language for serious numerical algorithms. The result of -1/(-1) should not be up to the vendor to define!

  • by steveha ( 103154 ) on Wednesday August 07, 2002 @05:42PM (#4028554) Homepage
    I read an article recently about a C extension to Python that very efficiently (and correctly) handled multi-dimensional matrix math. Thus you can write code using the very nice syntax of Python and still get good performance. The author of the article said something like "No one who has tried Python with these extensions ever wants to go back to FORTRAN."

    It made me wonder if, with enough C extensions, Python can take over FORTRAN's niche as a high-performance heavy number-crunching language.

    I don't know enough about the issues to make any predictions; I'm just wondering.

    steveha
    • Eventually it will. Look at www.scipy.org. They have a module called weave. With that module you can mix C-code into Python-code. The C-code is compiled when you run the program the first time and then you have a fast module.
      There are also some modules which allow the linking of FORTRAN subroutines into Python code.
  • by markmoss ( 301064 ) on Wednesday August 07, 2002 @09:43PM (#4030017)
    "25 year old language." No it's a 45 year old language, more or less. It was created in the 1950's, and had major revisions in 1964, 1977, and 1990. I'm personally familiar only with before & after '77 - this was a very big revision. The only "structured" control statement in FORTRAN 64 was the DO loop, a crude precursor to for loops; the end of the loop, IIRC, was marked by a line number, and it would execute the loop once even if the parameter values indicated it should execute 0 times. All IF statements, if evaluated true, did a GOTO, and the target was a line number, not even a label. And I found the FORMAT statement (roughly equivalent to printf) to always be a big pain, but there was no other way to print anything at all. But it was possible to write big programs in it, and the other choices of the era - COBOL, assembly, and various toy languages written by ivory tower types as demos - were often even less atractive. IBM even wrote accounting programs in it (using a hammer to drive screws because someone else invented the screwdriver, I mean COBOL), until they developed PL/1, which looked sort of like FORTRAN with certain critical ideas out of COBOL added whether or not they fit in...

    FORTAN 77 had control structures like IF-THEN-ELSE, WHILE, etc., so you didn't have to write GOTO line number. It smoothed various other issues out, but to make it backwards compatible it kept much of the peculiar look of F-64: all caps, lines actually starting in column seven to leave room for up to five digit line numbers and a continuation mark in column six, I think even the reservation of columns 72-80 for sequence numbers so you could have a card sorter straighten out a dropped deck (not that anyone I knew ever used this feature - it made it kind of difficult to swap the cards around for debugging.)

    Anyway, FORTRAN was primarily designed for number crunching, and AFAIK it still compiles the fastest straight number crunching code. Part of this is due to the many "advanced" features that hadn't been invented in 195x when it was first written. For instance, functions and subroutines have their own name spaces (like most languages since, except the first releases of BASIC), but the storage is static by default. So it doesn't spend time creating and destroying local variables on the stack, but OTOH you tend to use more RAM and recursive code was out of the question at least until F-77. There are (or were) no data structures (aka records). There are no pointers - you must use arrays anywhere a C programmer would use pointers. This vast loss of flexibility has the payoff that for the general run of numeric array operations, the compiler can tell what you are trying to accomplish and optimize it better than C compilers can, and even use parallel processors where available.

    Still, IMHO, programming in FORTRAN sucks once you learn real progrsamming. But it is easier for mathematicians/engineers/physical scientists to use FORTRAN's arrays than C's pointers and structures, and the compiled code really zips.

It is impossible to enjoy idling thoroughly unless one has plenty of work to do. -- Jerome Klapka Jerome

Working...