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?

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

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.