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?

[What'sInAName]

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?

[YankeeInExile]

I am sure most of these programs are small and maintained by a few people.

Actually, most production FORTRAN systems are beheamoth systems for modeling very complex behaviors. Although the community that keeps these systems up-to-date is probably relatively small.

But not always: My friend Carl was writing CGI in FORTRAN to run on the XKL TD-1

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:Learning It?

[avandesande]

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.

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.

Fortran >=90 is nice and easy to learn

[poszi]

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.

Re:Learning It?

[Peter La Casse]

doesn't gcc include a fortran compiler? (g77?)

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?

[rebelcool]

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.

Re:Learning It?

[mz001b]

There's a new GCC Fortran 95 compiler under development ("gfortran") that will be officially released with GCC 4

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.

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:FORTRAN considered useful...like SQL

[Tablizer]

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.

Re:Learning It?

[DoctorRad]

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/).

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

[seminumerical]

I loved the fact that everything was pass by reference

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

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

Re:FORTRAN - The ugly but lovable little SOB

[Tony-A]

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.

Re:hardly unfortunate

[Fruit]

Actually C has those too:

int main(void) {
char x[7][13];
printf("%d\n", sizeof x);
return 0;
}

% ./a.out
91

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

[Dachannien]

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.

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.

Re:Nothing for you to see here, please move along.

[locofungus]

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.

Re:hardly unfortunate

[Mr2001]

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?