Slashdot Mirror
How Not to Write FORTRAN in Any Language
gManZboy writes "In an article that's sure to p/o Fortran programmers, Donn Seeley has assembled a rant that posits there are characteristics of good coding that transcend all programming languages, except Fortran. Seriously though, his point is that early FORTRAN made coding ugly. Thus the joke 'Don't write FORTRAN' was applied to anyone with ugly code. Though Fortran has in recent years overcome its early challenges, the point -- 'Don't write FORTRAN' (i.e. ugly stuff) -- still applies."
Well, I'm by no means an uber-coding guru, but I used to prgram in C, and I just finised a three-year job writing many little programs in Fortran 90. I liked it, for what it is. The modern variants of Fortran are, in general, much nicer to look at, and if you know C and/or other languages, you could probably pick it up pretty easily.
I think I found basic i/o to be much easier in Fortran than C, but then that might be because my C is so rusty I have to keep re-looking everything up. Oh well.
For a (mostly Fortran-like) language that has a free compiler, you might also take a look at F as well. (http://www.fortran.com/F/).
But not always: My friend Carl was writing CGI in FORTRAN to run on the XKL TD-1
How does the Slashdot Effect happen given that no slashdotters ever RTFA?
You're kidding, right? FORmula TRANslation was meant for solving problems in numerical methods. It is still one of the best languages in the world for solving those kinds of problems. No, it was never meant to write operating systems (but apparently is was used for at least one OS). It is also a highly portable language; iff you stay away from extensions. If you are looking for good numerical code, you probably end up at Netlib. And most of that is probably still FORTRAN. Some people have even written C/C++ interfaces to FORTRAN numerical libraries, because the FORTRAN code is still the best implementation for solving the problem.
Yes, please do write good code. Poorly written code is a pain in any language.
The special thing about Fortran is that you can process a whole vector instead of using a for() loop. This makes it easy for compilers to break up tasks among multiple processors.
love is just extroverted narcissism
We are actually in the process of changing the printer-friendly version to display the article all on one page. Sorry it's not ready today, hopefully by next week.
Ed Grossman, InformationWeek
Maybe, and absolutely. Note that the article ignorantly used FORTRAN to mean FORTRAN 66. In fact, Fortran 90 has all the features of a modern programming language. Add to that the fact that fixed-format produces far prettier looking code than C's mess of curly braces and parentheses, although you can also use free-format if you choose. Really, the article makes no sense if you look at what FORTRAN is today.
Answering your questions directly:
Fortran 90 does array, vector, and matrix processing better than any other language, and can do some parallelization of vector processing with a compiler flag. If you're doing scientific programming, Fortran 90 is really the language you should be using. On the other hand, for programs that are actually supposed used by laypeople, there's not much support for doing that with FORTRAN.
Unfortunately, FORTRAN has achieved a role in scientific computing it will probably never lose. One co-worker of mine was a recent physics PhD who spent his entire academic career trying to persuade his fellow scientists that they'd save themselves a lot of grief by switching to C -- with no success.
While Fortran 77 is ugly and I saw terrible programs written in Fortran 77, Fortran 90 or 95 is a pretty modern and nice language and if you know C, it is easy to learn Fortran 90. It is not that much different from anything else. It is great in numerical programs (especially linear algebra) as the matrix handling is nice and fast. The only problem is that only recently free (as in speech) Fortran 90 compilers has become available and they are still in beta stage. However, for Linux, Intel Fortan Compiler is free (as in beer) and works fine. It includes also documentation of the language so you may try it.
Save the bandwidth. Don't use sigs!
It does, but it's starting to show its age. There's a new GCC Fortran 95 compiler under development ("gfortran") that will be officially released with GCC 4.
Alot of it has to do with legacy scientific and engineering libraries. There are millions of lines of proven libraries that were originally written in the 60s and 70s for various scientific and engineering analysis disciplines.
When I was at the university of texas, there was a parallel programming course that was conducted in fortran and c++. The professor of it quoted how much it would cost in labor and manhours to transfer all those fortran libraries to a more "modern" language - and it was many many millions of dollars and years of work. So, the course taught parallel programming by having students doing this work! It was fairly successful, and is probably still taught. The converted libraries generated by students are in use in several fields. It was alot of parallel linear algebra libraries, IIRC.
-
and an even better, almost working one, g95 -- this is the code base that the gfortran people forked from. gfortran does not work, and is much further behind than g95.
The p/o'd response basically sounds like "He's equating Fortran with FORTRAN-66 (or 77)".
I know that I do this too. When someone says "It's written in FORTRAN" I don't think Fortran-95, I think FORTRAN-77... and I'm usually right.
I suspect that there are two reasons for this:
It reminds me of SQL in that respect. I have worked with managers who knew less about computers than their secretaries, but they were able to use SQL to write queries to get information that they wanted. SQL was written for that purpose. It ain't pretty, but it serves its target market.
Target market? Do you mean when IBM first designed it, or how it is actually used now? Most SQL "users" are developers. However, SQL is poorly suited for developers. Beyond a single SELECT statement, SQL's flaws start to pile up pretty quick. I think it is time to replace SQL with a better relational language. A RDBMS can perhaps use both SQL and the replacement so that non-techies can use the more English-like SQL if desired.
Alternatives include Chris Date's "Tutorial D". I am also working on a replacement, tentatively called "Tops Query Language". However, I don't think they will catch on because SQL can fixed to be "good enough" if the industry is ever pushed to improve the situation.
Table-ized A.I.
Seconded. F is a subset of Fortran95, with all the deprecated syntax options taken out. This promotes good coding style. Any F program will compile with a f95 compiler, so you can get the same code running on much bigger machines very easily.
Matt...
Save the Bottom Line
Actually, FORTRAN IV, on some computers of the day (I think IBM 360/370 using FORTRAN's G or H), used pass by "value and result" rather than pass by reference. There were so many differences amongst the dozens of dialects of FORTRAN out there in my day (late 70's) that portability was nonexistent and I changed languages.
In wartime... truth is so precious that she should always be attended by a bodyguard of lies. (Churchill)
Libraries - the most bullet-proof, battle-tested numerical code is pretty much all in FORTRAN
Optimizers - if you must wring the last factor of two of performance out of big vectorizing iron, and you're not a CS guru, the FORTRAN compiler is still your best bet
Semantics - FORTRAN the language enforces some constraints that make vectorizing optimization work better than less constrained stuff like C
The problem is, for these guys FORTRAN is a means to an end - most of them have had very little formal training in good coding practice, and worse, most of the code they read was written by people with similar experience.
Maybe what we should do is require scientists and engineers to pair-program with recent CS graduates. Both sides would learn a lot from that.
To a Lisp hacker, XML is S-expressions in drag.
What about APL? If you're in for cryptic but powerful languages, of course.
" it's a lot quicker to write/maintain makes most of that speed differential meaningless." No it doesn't. Some of the FORTRAN code is used in algorithms that do things like Finite Element Analysis, High Energy Physics and Weather Prediction where it is not uncommon for something to run for HOURS or run many times with different variable settings (i.e. Monte Carlo). These systems invariably use highly optimized FORTRAN code. CPU time is NOT free and often an Engineer is charged a "tax" by IT for his CPU useage over his allocation. You only save the programmer time once, you save execution time EVERY run. I've worked in the Aerospace biz many years and have never seen big number crunching programs done in C/C++ or Java. I have seen some Assembler but not much. I've also written C code for embedded systems and I do know it can be written very efficently, but it's not at all optimized for Math thus FORTRAN beats it.
Tended to be FORTRAN for scientific computing and COBOL for business computing, with the two groups never communicating with each other.
Then there was PL/I which allows writing FORTRAN and/or COBOL within an ALGOL structure.
In addition to the punch-cards, remember that second generation mainframes were the equivalent of 64k bytes. Cramped, very cramped. The 7070 was 10,000 10-digit words (decimal) with three signs, which comes out in the same neighborhood.
Unfortunately, g95'S developer chose to rather violate the GPL than to either work together with the gcc people or at least let them use his code. Look here for more information on the split.
Either that's a bad example, or compiler optimization has come a long way, baby. Or maybe I just don't get what you're getting at. But a quick test using gcc reveals this:
http://sokar.cwru.edu/multidim.html
Note that the code that calculates the offset into the x array (italicized for convenience) is one instruction shorter for x[i][j] rather than the code you listed.
I know this for a fact as I have written graphics software that treated multidimensional arrays as a contiguous blocks of memory accessing it using x[i][j] notation and iterated pointer notation depending on the circumstance and both worked the same. I have also read the assembler output from a C compiler and it indeed compiled x[i][j] the same as *(&x + 10*i + j).
To further back up my statement here is a direct quote from Kernighan and Ritchie's "The C Programming Language" Chapter 5:
So the notation x[i][j] will compile down to either *(&x + 10i + j) or *(*(x+i) + j) depending on whether x was declared a true multidimensional array or an array of pointers.
One caveat (and possible source for your confusion) is that when declaring a true multidimensional array you must know the dimensions at compile time. You cannot for example declare x[width][height], and if you allocate a chunk of memory with malloc, you can access it as a single-dimensional array using the x[i] notation, but there is no notation for treating it as a multidimensional array. I have had to manually index dynamically allocated chunks of data using *(&x + 10i + j) before, and I agree it is a pain. Fortunately C++ fixed that and you can allocate multidimensional arrays at runtime and use the x[i][j] notation.
To be fair however, I'm pretty sure that FORTRAN 77 did not have automatic or allocatable arrays either - there were some implementation-specific ways of doing it, but it was not officially added until FORTRAN 90. But I am young enough that FORTRAN 90 was my first FORTRAN, and what I know about 77 is only from historic reading, not experience, so take that with a grain of salt.
For the second case:
#include <iostream>
class A { public: virtual void do_something() { std::cout << "A" << std::endl; } };
class B:public A { public: virtual void do_something() { std::cout << "B" << std::endl; } };
void myfunc(A& a) {
a.do_something();
}
Does this code print A or B when myfunc is called? Which do_something() is executed? Unless you are using function pointers, this ambiguity does not exist in C (or FORTRAN)
For the first case I wrote:
There is no way of telling just by looking at this code.
in C if I have int i; do_something(i); I know that i doesn't change. I don't need to look at the prototype (ok do_something could be a macro)
What I would have liked is for the caller to a non-const reference to still have to write that '&'. The callee gets the benefit of the reference and anyone looking at the caller code immediately knows that there might be something happening that isn't explicit in the code they are looking at.
In theory a smart syntax highlighter could do this but it would probably have to almost be a compiler to handle this, especially if you want it to be correct, even in the face of macros. And I don't want to have to wait for a compilation every time I load a file up into my editor.
An editor could not handle something like:
#ifdef REALLY_SCREW_THINGS_UP
void shit(int& i) { i=i+1; }
#else
void shit(int i) { }
#endif
int main() {
int i=0;
shit(i);
}
But a compiler could have refused to compile unless that call in main was changed to shit(&i); if REALLY_SCREW_THINGS_UP was defined.
God said, "div D = rho, div B = 0, curl E = -@B/@t, curl H = J + @D/@t," and there was light.
http://rchrd.com/Misc-Texts/Famous_Fortran_Errors
... `R dot bar n' [R overstruck `.' and `_' and subscript n],
>From the alt.folklore.computers FAQ:
III.1 - I heard that one of the NASA space probes went off course and
had to be destroyed because of a typo in a FORTRAN DO loop.
Is there any truth to this rumor?
As revealed by past discussion in comp.risks (Risks Digest) as well as
alt.folklore.computers and occasionally other newsgroups, this turns
out to be a confusion of two separate events.
The space probe that the DO-loop story has been wrongly attached to is
Mariner I (or 1), which was intended for Venus (not Mars). Several
incorrect or partially correct versions of what really happened were
posted in comp.risks; the best of these cited a NASA publication called
"Far Travelers" by Oran W. Nicks, but still did not have the whole story.
Then in issue 8.75 we found out what really happened...
| Date: Sat, 27 May 1989 15:34:33 PDT
| From: Peter Neumann
| Subject: Mariner I -- no holds BARred
|
| Paul Ceruzzi has written a truly outstanding book for the new show
| that opened two weeks ago at the Smithsonian National Air and Space
| Museum. The exhibit and the book are both entitled "Beyond the Limits
| -- Flight Enters the Computer Age". Both are superb. Go for it (them).
|
| Paul has dug into several cases treated previously in RISKS and in
| issues of the ACM Software Engineering Notes, and has been able to
| resolve several mysteries. In particular he considers the case of
| Mariner I, about which various inaccurate stories have been told.
| Intended to be the first US spacecraft to visit another planet, it was
| destroyed by a range officer on 22 July 1962 when it behaved
| erratically four minutes after launch. The alleged missing `hyphen'
| was really a missing `bar'. I quote from Paul's book, pp. 202-203:
|
| # During the launch the Atlas booster rocket was guided with the help
| # of two radar systems. One, the Rate System, measured the velocity of
| # the rocket as it ascended through the atmosphere. The other, the
| # Track System, measured its distance and angle from a tracking
| # antenna near the launch site. At the Cape a guidance computer
| # processed these signals and sent control signals back to the
| # tracking system, which in turn sent signals to the rocket. Its
| # primary function was to ensure a proper separation from the Atlas
| # booster and ignition of the Agena upper stage, which was to carry
| # the Mariner Spacecraft to Venus.
| #
| # Timing for the two radar systems was separated by a difference of
| # forty-three milliseconds. To compensate, the computer was instructed
| # to add forty-three milliseconds to the data from the Rate System
| # during the launch. This action, which set both systems to the same
| # sampling time base, required smoothed, or averaged, track data,
| # obtained by an earlier computation, not the raw velocity data
| # relayed directly from the track radar. The symbol for this smoothed
| # data was
| # where R stands for the radius, the dot for the first derivative
| # (i.e., the velocity), the bar for smoothed data, and n for the
| # increment.
| #
| # The bar was left out of the hand-written guidance equations. [A
| # footnote cites interviews with John Norton and General Jack Albert.]
| # Then during launch the on-board Rate System hardware failed. That in
| # itself should not have jeopardized the mission, as the Track System
| # radar was working and could have handled the ascent. But because of
| # the missing bar in the guidance equations, the computer was
| # processing the track data incorrectly. [Paul's EndNote amplifies:
| # The Mariner I failure was thus a {\it combination} of
An example:In Fortran, you can take "sections" of arrays. Also, although indices start from 1 by default, you can specify the lower limits if you like, as in the first array "a" above, which has -1 as the lower limits of the first two dimensions. Intrinsic functions can be applied to arrays and sections of arrays. The language has the syntax for these features. In C++ the above code would beBut then, you have to remember i+2 for "a" corresponds to i for "b" and "c" because the lower bound of array indices are always 0 in C++.
Array sections can be used as arguments to subroutines, as inIn C++, you can do this by defining a class representing multidimensional arrays. You would define arithmetic operations (+, -, *,
And even then, a C++ compiler can't apply as much optimization to your code as a Fortran compiler can. For example, a Fortran compiler can easily transforminto the one-dimensionalizedThe compiler can do this because arrays are native types and because the compiler knows the memory for each array is contiguous. Can a C++ compiler transformlikewise? I doubt it. I think a C++ compiler has to generate a temporary for the result of sin(b), cos(c), and tan(d), and add the first two temporaries, and then the third to get the final result.
If there's a sizable demand for numerical computations in C++, then vendors would create a C++ compiler which has a built-in capability of efficient and convenient array operations and other stuff (like native complex numbers). But, that won't happen because people doing numerical computations are largely happy with Fortran 95 and those aren't happy with the language interested in numerical computations. Only minority of people (like me) aren't quite happy with Fortran 95 *and* are doing numerical computations.
In C, multidimensional arrays are a fiction, because a[i][j] is given exactly the semantics of *(*(a + i) + j), instead of *(a + i * second_dim + j).
Poster has absolutely no clue what s/he is talking about.
One caveat (and possible source for your confusion) is that when declaring a true multidimensional array you must know the dimensions at compile time. You cannot for example declare x[width][height]
I'm pretty sure GCC lets you do that, doesn't it?
Visual IRC: Fast. Powerful. Free.