How Not to Write FORTRAN in Any Language 502
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."
Re:Learning It? (Score:2, Informative)
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/).
Re:FORTAN programs are small right? (Score:3, Informative)
But not always: My friend Carl was writing CGI in FORTRAN to run on the XKL TD-1
Re:Learning It? (Score:3, Informative)
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.
Re:Learning It? (Score:3, Informative)
Re:Article format (Score:4, Informative)
Re:Learning It? (Score:5, Informative)
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.
Re:FORTRAN - The ugly but lovable little SOB (Score:5, Informative)
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.
Fortran >=90 is nice and easy to learn (Score:3, Informative)
Re:Learning It? (Score:3, Informative)
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.
Re:Why use FORTRAN these days? (Score:3, Informative)
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.
Re:Learning It? (Score:3, Informative)
and an even better, almost working one, g95 [g95.org] -- this is the code base that the gfortran people forked from. gfortran does not work, and is much further behind than g95.
Why FORTRAN makes people think FORTRAN-66 (or 77) (Score:4, Informative)
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:
Re:FORTRAN considered useful...like SQL (Score:2, Informative)
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.
Re:Learning It? (Score:2, Informative)
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...
Re:A great programming language (Score:2, Informative)
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.
FORTRAN gets its bad reputation... (Score:4, Informative)
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.
Re:Learning It? (Score:1, Informative)
Re:Speed of Fortran (Score:4, Informative)
Re:FORTRAN - The ugly but lovable little SOB (Score:3, Informative)
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.
Re:hardly unfortunate (Score:2, Informative)
GPL (Score:4, Informative)
Re:hardly unfortunate (Score:2, Informative)
Re:hardly unfortunate (Score:3, Informative)
http://sokar.cwru.edu/multidim.html [cwru.edu]
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.
Re:hardly unfortunate (Score:5, Informative)
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.
Re:Nothing for you to see here, please move along. (Score:2, Informative)
#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.
Two conflated events (Score:1, Informative)
>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
Re:hardly unfortunate (Score:1, Informative)
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 be But 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 in In 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 transform into the one-dimensionalized The 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 transform likewise? 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.
MOD DOWN (Score:1, Informative)
Poster has absolutely no clue what s/he is talking about.
Re:hardly unfortunate (Score:2, Informative)
I'm pretty sure GCC lets you do that, doesn't it?