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

FORTRAN - The ugly but lovable little SOB

[ChuckleBug]

When I took computer programming in high school, it was all FORTRAN. We used a wonderfully dry textL FORTRAN IV with WATFOR and WATFIV. We didn't have any sort of microcomputer (this was 1980, and we were behind the times even then), but we had a keypunch, so we'd write code on a form, punch cards, rubber band 'em together, and send them off to be run on the district's big iron. Then you'd wait a week and get back a few sheet of green and white striped paper with ***SYNTAX ERROR*** all over it. And we liked it that way!

Although that was a toothache of a programming experience, I have never lost this bizarre fondness I have for that ugly, unwieldy, but somehow cool FORTRAN. Writing that stuff makes you feel like you're talking the language of a retro-scifi computer, like the ones in the original Star Trek that spoke in that odd mechanical monotone. Robby the Robot had to
have been programmed in FORTRAN (and NO he was NOT a guy in a suit! I'm not listening! La la la!).

At any rate, old-fashioned FORTRAN may deserve to be bashed, but I can't help shedding a tear.

A great programming language

[toddbu]

Back in the good old days before C/C++ was popular, FORTRAN was a great programming language for doing anything that had to do with math or bit manipulation. The alternatives were things like COBOL or Pascal. What I loved about FORTRAN was that you could do cool things like treat strings as ints or do negative subscripting to rewrite the OS. I had a graphics class that I wrote some FORTRAN code in because I could break down a matrix into a single row just by passing in a pointer. I loved the fact that everything was pass by reference, which is why it took me so long to switch to C. If you had an optimizing compiler you could do stuff like make 1 == 2 because the constant value 1 was mapped to the same memory location for all instances and if you passed the constant into a function then you change the constant value inside the function.

I prided myself in college that I could write FORTRAN in any language. I had a prof that couldn't figure out why I was doing bit manipulation in COBOL. (Yes, this can be done in COBOL through multiplication and division, but it's really ugly.)

Yes, older languages can be ugly...

[Richard Steiner]

...but it's still quite possible to write readable and modular code even in Fortran 66.

(I'm saying this as a programmer who spent 12 of the past 15 years doing exactly that -- writing and maintaining Fortran 66 code that was part of a critical production system at a major airline).

As with any language, the onus is on the programmer who is writing the code to organize it and implement it in a way which is easy for subsequent programmers to follow and understand.

We were able to do it even within the limits and conventions present in the environment (external variable/parameter references limited to six (6) characters, internal references limited to either five (5) or one (1) character, subroutine names limited to six characters) by using common sense and trying to use a consistent coding style.

Yes, arithmetic IFs are ugly, computed GOTO statements can be confusing, and strings defined using Hollerith notation are strange to folks who haven't seen it before, and programs are hard to follow when everything is lined up neatly in column 7 without any spacing between code and comments. So don't use that style, avoid confusing notation, and refrain from using confusing syntax or statements which might make the intent of the program unclear.

It's the same advice in any languages -- cute tricks might save a few bytes or clock cycles, but in a production environment it's usually long-term MAINTAINABILITY that counts -- and that's true in *any* language!