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."

Comments

Re:Learning It?

[Anonymous Coward]

Are there things that it does a lot better than other languages?

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:Article format

[gManZboy]

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.

Re:Learning It?

[phritz]

Is Fortran worth learning? And are there any things that it does a lot better than other languages?

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

[fm6]

The problem with FORTRAN is that it was the very first high-level programming language. ("High-level" meaning a language that allows you to think in formulas and variables, not operation codes and registers.) So they had to make all the mistakes that taught computer scientists how not to write a grammar. Which mistakes produced a language that is both difficult to code and difficult to parse.

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.

Why FORTRAN makes people think FORTRAN-66 (or 77)

[Glomek]

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:

1. FORTRAN-77 was the big thing during FORTRAN's heyday, so most of the legacy FORTRAN code out there is FORTRAN-77.

2. For a long time, the best Free Software FORTRAN compilers out there (g77, f2c) have been FORTRAN-77 compilers. g95 is still fairly young.

FORTRAN gets its bad reputation...

[alispguru]

... from scientist and engineer coders. For these guys, FORTRAN is the only reasonable way for them to turn their domain knowledge into production code, for three main reasons:

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:Speed of Fortran

[twiddlingbits]

" 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.

GPL

[Bananenrepublik]

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.

Re:hardly unfortunate

[pavon]

You are misinformed. char x[5][10] does allocate a contiguous block of memory, and x[i][j] does index that memory the exactly as if you were to write *(&x + 10*i + j) !

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:

5.9 Pointers vs. Multi-dimensional Arrays
Newcomers to C are sometimes confused about the difference between a two-dimensional array and an array of pointer such as name in the example above. Given the definitions.

int a[10][20];
int *b[10];

then a[3][4] and b[3][4] are both syntactically legal references to a single int but a is a true two-dimensional array: 200 int-sized locations have been set aside, and the conventional rectangular subscript calculation 20×row+col is used to find the element a[row][col]. For b, however, the definition only allocates 10 pointers and does not initialize them; initialization must be done explicitly, either statically or with code. Assuming that each element of b does point to a twenty-element array, then there will be 200 ints set aside, plus ten cells for the pointers. The important advantage of the pointer array is that they rows of the array may be of different lengths. That is, each element of b need not point to a twenty-element vector; some may point to two elements, some to fifty, and some to none at all.

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.