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.

fool!

[Anonymous Coward]

sure to p/o Fortran programmers

You mean "sure to p .divide. o Fortran programmers.

Excellent points

[YankeeInExile]

While I take issue with his blantant anti-FORTRANism, he makes the excellent point: Write good code in whatever language you write. Just because you can write Perl that looks like line noise does not meen you must.

Missing something

[Anonymous Coward]

In an article that's sure to p/o Fortran programmers and bore the hell out of everyone else, Donn Seeley...

You can write beautifully in ANY language...

[Anonymous Coward]

As long as you use vi. You can never write beautiful code with emacs

I just figured I'd follow one pointless flame fest with another.

About time someone spoke up about Fortran.

[bigtallmofo]

Seriously, it's about time that someone knocked Fortran programmers down a peg or two. It seems impossible to get any type of programming job if you don't know Fortran.

Every job classified ad section is filled to the brim with Fortran positions while less relevant languages like Java, C# and Visual Basic are almost completely neglected.

I for one welcome news like this if it help Fortran programmers acquire just a little humility.

Article format

[hobit]

It would be nice



if the article weren't broken



into such small pieces.



That way I could



print it for my students.

Sort of amusing for an article that discusses using white space in a good way.

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.

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!