How Not to Write FORTRAN in Any Language 502
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."
FORTRAN - The ugly but lovable little SOB (Score:5, Interesting)
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.
Learning It? (Score:5, Interesting)
I mostly program in C, Java,php and C++(and several other languages that I dont use as much), and am always interested in picking up new languages to play around with. Is Fortran worth learning? And are there any things that it does a lot better than other languages?
Oy.. The code I've seen.. (Score:2, Interesting)
I'm more of a western coder ... lots of wide open spaces in between clauses for readability. Documentation in bits rather than 100 lines of code then a paragraph about what happened in there.
I'm sure someone somewhere would gripe about my style too.
FORTAN programs are small right? (Score:5, Interesting)
I have had to make changes to UNIX shell scripts and PERL code before. Most of the undocumented cryptic scripts were small enough to figure out what I needed to change.
Re:FORTAN programs are small right? (Score:3, Interesting)
Yes, FORTRAN is very common for engineering calculations: I've written things like distillation column models in it. It's fast, simple and there are lots of numerical libraries for it. I wouldn't want to use it on a project I had to maintain, but for getting the job done it's pretty good.
A great programming language (Score:5, Interesting)
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.)
Re:One man's ugly skank... (Score:3, Interesting)
And assembly is pretty? (Score:2, Interesting)
Kinda reminds me of "Back to the Future III" where Marty plays that shoot-em-up arcade game in front of kids, and all they can do is complain "You mean you have to use your hands. That's like a baby's toy."
I, for one, look forward to the day when I can think code and have it be done instead of writing it line-by-line.
You would have thought... (Score:4, Interesting)
Re:FORTAN programs are small right? (Score:3, Interesting)
SMALL?
When I did some lab as part of my CS study, one unfortunate group of four students got the assignment to write documentation for part of some FORTRAN behemoth written over 15 years by successive grad students in the math department. It was horrible.
It was worth four credits (= 4 weeks), so documenting part of that small program was supposed to take four man months.
Our group wrote a GUI in Tcl/Tk interfacing VTK to show nice 3D graphs of the output of that program. We were lucky we could look at some smaller FORTRAN programs that were used to parse the stuff before then, only a few thousand lines, but it was still hardly possible to figure out what was what.
No namespaces...
Re:FORTRAN - The ugly but lovable little SOB (Score:5, Interesting)
My highschool offered its first computer science course, and I took the first class.
We had Apple computers running Basic, NEC (or was it NCR?) machines running Fortran, 2 terminals and a printer/terminal connected to a mini computer at school district headquarters.
I don't recall the specifics of the version of fortran - all I recall is you would actually boot the machine into a fortran interpreter, then you would type in your program by hand and run it. We might have been able to save our application onto a 5 1/4" floppy disk not sure...
The only printer was the terminal - so if you wanted a printout, you had to login via terminal/printer and output your program contents (provided you had typed it in previously and saved it) and/or run it to capture the output. I want to say the system could run both basic and fortran applications - so access to the printer/terminal was always tight - particularly if a project was due.
This was my first experience with a time-sharing system - we had quotas - that if we went over the number of hours alotted we would be denied access. The eggheads in our group loved the mini and tuned up their noses at the little micros in the lab.
I played dungeon (precursor to the Zork trilogy)on the county's computer, in addition to doing my assigned tasks, and spent many hours in the computer room after school. I recall one kid claiming to have changed his grades on that machine (apparently all of our grades were entered in the mini through terminals in the school office) - but I never validated that.
We did a lot of flow charts and wrote our programs out before entering them in the system (or we were supposed to). Just glad we did not have to deal with paper tape/punch cards - although punch cards were to revisit me in a few years (I unintentionally played 52 card pick-up with a deck of them when delivering them to a data center - but that is another story).
I wonder what kind of programming classes are available in highschools today? My daughter took a course involving HTML and CSS markup - but I don't recall seeing any programming classes on her curriculum. Are kids learning java/perl/python like we learned basic/fortran?
Re:Learning It? (Score:3, Interesting)
1) Array, vector, and matrix processing can not only be done better, but with FAR less work in MATLAB, and using their converter, will nicely produce C (C++?) on the other end.
2) Parallelization of vector processing can also be done with >version R11 of Matlab, again with many fewer lines of codes, using a toolkit. (see here [mathworks.com])
A couple years ago I was working on some "Cutting Stock" optimization problems. The current system was written in Fortran, but Matlab was the language of choice for the new one. Its probably more expensive, but talk about saving you some trouble in the long run...
Re:FORTRAN - The ugly but lovable little SOB (Score:2, Interesting)
SUBROUTINE FOUR1 (DAT,NN,ISIG)
c This is a Cooley-Tukey fast-Fourier trans-
c form in FORTRAN. Transform(K) =
c Sum(DATA(J)*exp(ISIGN*2*Pi*Sqrt(-1)
c *(J-1)*(K-1)/NN), summed over all J and K
c from 1 to NN. The data is a one-dimensional
c complex arra, i.e., the real and imaginary
c parts are adjacent in storage, as FORTRAN
c places them. The array's length is NN =
c 2**K. If necessary, append values to th
c data to reach an even power of two.
c ISIGN is +1 or -1; a -1 transform followed
c by a +1 transform (or vice versa) returns
c the original data multiplied by NN. The
c transformed data are returned in the
c array DATA, end replace the original input.
DIMENSION DAT(*)
N = 2*NN
J=1
DO 5 I=1,N,2
IF (I-J) 1,2,2
1 TEMPR=DAT(J)
TEMPI=DAT(J+1)
DAT(J)=DAT(I)
DAT(J+1)=DAT(I+1)
DAT(I)=TEMPR
DAT(I+1)=TEMPI
2 M=N/2
3 IF (J-M) 5,5,4
4 J=J-M
M=M/2
IF (M-2) 5,3,3
5 J=J+M
MMAX=2
6 IF (MMAX-N) 7,10,10
7 ISTEP=2*MMAX
THETA=6.2831853/FLOAT(ISIG*MMAX)
SINTH=SIN(THETA/2.)
WSTPR=-2.*SINTH*SINTH
WSTPI=SIN(THETA)
WR=1.
WI=0.
DO 9 M=1,MMAX,2
DO 8 I=M,N,ISTEP
J=I+MMAX
TEMPR=WR*DAT(J)-WI*DAT(J+1)
TEMPI=WR*DAT(J+1)+WI*DAT(J)
DAT(J)=DAT(I)-TEMPR
DAT(J+1)=DAT(I+1)-TEMPI
DAT(I)=DAT(I)+TEMPR
8 DAT(I+1)=DAT(I+1)+TEMPI
TEMPR=WR
WR=WR*WSTPR-WI*WSTPI+WR
9 WI=WI*WSTPR+TEMPR*WSTPI+WI
MMAX=ISTEP
GO TO 6
10 RETURN
END
Blast from the Past (Score:3, Interesting)
[A two page ad. A middle-age man with a youthful, shy grin, dark horn-rimmed glasses, slicked, short hair, and the premonition of a hairy chest emerging from a blue denim(?) shirt, fills the left page; the vista of urban sprawl outside a window behind him; painted scrawls of mathematical formulas superimposed. On the right hand page is a block of sans-serif text]
Meet an elder statesman in the computer business.
IBM's Jon Backus is 43, pretty young for an elder statesman in most industries. But then, the computer business is less than 20 years old and a mathematician Bakcus has been in it since the beginning. He started workig with computers in the early 1950's. It was about the time a leading business magazine estimated that no more than 50 companies would ever have use for a comptuer. Today, it is estimated that there are well over 50,000 comptuer installations in the United States alone. Part of the reason for this astonishing growth: the progress made in programming. In this field, John Backus was a pioneer. "It bothered us, in the early days of computers, that so few people coluld use them" he says. "One reason was, programming cost as much as the machine. A small compnay just couldn't afford data processing." With a small group of associates, John Backus tackled the problem and stayed with it for three years. The result was the simplified programming system called FORTRAN (FORmula TRANslator) which made programming considerably less expensive than before. Today, FORTRAN is probably the most widely used programming system in the world. Currently, John Backus is working on a new mathematical concept which is still in the realm of pure theory. But his theories, like the work of many IBM scientists, ultimately have a way of making computers more useful.
[A red line runs across the text. A matching red 'IBM' (not the blue, CRT lines version) appears in the margin.]
From a beginning less than two decades ago, computer technology has made remarkable progress. John Backus is one of many outstanding men and women in the industry who have turned a laboratory marvel into tens of thousands of computers helping people around the world.
Yes, older languages can be ugly... (Score:5, Interesting)
(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!
Re:FORTRAN - The ugly but lovable little SOB (Score:1, Interesting)
If the kids are in AP Computer Science, they are learning Java, if they had the course this year or last year, or C++ if they had the course before last year (e.g. 2 years ago). However, like with FORTRAN, most of these kids are not writing good code as the instructor usually does not ever really go through the source code, but just looks at the program output. The philosophy is that, if the program works, who cares what kind of dirty tricks were used to make it.
My first exposure to good code was really when I got a job as a web-developer and had to go through some Perl scripts written by an old-time programmer.
hardly unfortunate (Score:5, Interesting)
It is *possible* to write C that runs as fast as Fortran for heavy math. However, it involves hand-optimizing your C until this happens.
Fortran handles calculations quite well, thank you. It take less Fortran code to handle many common operations, and array options are built in and optimized to high heaven.
With Fortran 90 and 95, the grammars that led to the CS horror (e.g., computed gotos) are marked either deleted or obsolescent (meaning expect deletion in another standard or two).
Also, due to the selection of which features are included in Fortran and which are not, Fortran compilers can make much stronger assumptions than, for example, C compilers working with pointers.
There's nothing unfortunate at all about Fortran's (not FORTRAN any more) role in scientific computing. The tragedy is the number of people who bought into those silly C campaigns.
hawk
Even more scary? (Score:3, Interesting)
These are things man was not meant to do
Re:FORTRAN - The ugly but lovable little SOB (Score:2, Interesting)
As a side note, although our clients are Windows, the server is freeBSD, and were running OO.org. Within a year or two we should be completely switched to Linux. And some of the elementary schools in the area are alreadly pure linux.
Re:Yes, older languages can be ugly... (Score:5, Interesting)
Which led to the loss of a space probe, back in the day.
Re:hardly unfortunate (Score:3, Interesting)
With libraries like SPOOLES [netlib.org] I don't need to. One of the primary advantages of C is the availability of many libraries out there that have been developed over the years. Of course, this is in general. In specific domains (like particle physics) the great deal of Fortran code out there ensures that the language won't go away any time soon.
Re:Nothing for you to see here, please move along. (Score:5, Interesting)
For example, I initially resisted C++. I viewed it as poorly designed objects on C (after experiencing the beautifully done objects of LPC), and programming examples for it made objects of things that never should have been objects - and as such I wanted nothing to do with it.
However, the other features of C++ ended up proving themselves infinitely useful, and since the value of C++ objects has shot up notably in my mind. Examples:
Templates: I can't even imagine how many pieces of code I wrote before C++ in which I wrote different versions of the same function for different variable types. Talk about a maintainance nightmare
Const correctness: I remember resisting this like crazy, because it makes initial programming harder. But not only does it offer some serious benefits to the compiler at optimization time, but it's saved me many times from errors and really helped with code cleanup and refactoring into functions. My only real problem with it, now, is programmers who don't const their libraries, thus preventing me from consting variables that I need to pass to them at each step of the way.
Destructors: I don't think I need to even get into why having your variables clean up their memory when they go out of scope is probably the best thing that ever happened concerning fighting memory leaks. You can also do garbage collection with smart pointers, but that's a topic for some other time and is less standard.
std::vector: I can't believe that I used to not only have to clean up variable size arrays before, but used to have to have each array contain three variables - the pointer, the count of elements, and the allocated size - all of which would need to be checked and adjusted at each insertion and deletion.
std::string: A lot easier to use than C's unwieldy strings, and easy to convert to and from regular C strings.
I could go on for a long time... a good language can save you many programming headaches if you're willing to learn it.
Re:Learning It? (Score:3, Interesting)
it has a strict but simple syntax (far fewer ways you can make unintentional errors, unlike, say C++)
it is blazingly fast (only writing in Assembly code could likely beat it in speed)
it has great compiler flags for parallel processing and optimization (just make sure you have "clean" code that doesn't jump in and out of loops)
it is easily portable (I can run code written for the CRAY X/Y-MP in the 1980s, on a G5 in 2005)
it has a well tested and supported library for almost all types of numerical methods and heuristics.
Other than that, it is pretty much worthless.{grin}
cheers- raga
Re:hardly unfortunate (Score:2, Interesting)
It is *possible* to write C that runs as fast as Fortran for heavy math. However, it involves hand-optimizing your C until this happens.
Actually, it doesn't any more. Hate to be the one to break it to you, but C hasn't stood still either.
Also, due to the selection of which features are included in Fortran and which are not, Fortran compilers can make much stronger assumptions than, for example, C compilers working with pointers.
BZZT, wrong! The latest version of C, "C99" (supported by almost every compiler out there, including GCC) adds a keyword that might be useful for you:
restrict
Here's how you use it. When you declare a pointer variable (maybe you have a function that accepts an array of floats), instead of going:
void myFunction(float *myListOfNumbers) {
you write:
void myFunction(float *restrict myListOfNumbers) {
What does that do? Well, when you 'restrict' a pointer, it means you are telling the compiler that the memory it points to will only ever be accessed by using that pointer. (And not, say, by some other completely different function that just happens to create the same pointer (value) and twiddle bits of memory independently.)
What does that _mean_? It means that you get the "FORTRAN memory access model", exactly where you want it, with just a few keystrokes. All the optimizations your FORTRAN compiler does, your C compiler will do too, since they become legal.
There's nothing unfortunate at all about Fortran's (not FORTRAN any more) role in scientific computing.
Indeed! As a working scientist, I'm sometimes happy that others still use junk like Fortran: less competition for me to worry about!
http://sc.tamu.edu/help/power/powerlearn/html/S
Re:FORTRAN gets its bad reputation... (Score:1, Interesting)
Re:hardly unfortunate (Score:2, Interesting)
>(and how do they compare to C++, with its use >of operators and templates?).
Fortran 90/95/2003 shines in its treatment of multidimensional arrays. It resembles Matlab, with the advantages (and disadvantages) of a compiled language. Here are some of its specific strengths:
(1) To dynamically allocate a 3D array the code is just
real, allocatable
allocate (x(n1,n2,n3))
It's messier in C++.
(2) The array can be passed to a function just as a scalar is, without needing to mess with pointers. Arrays know their own size, so the dimensions of the array need not be passed as function arguments.
(3) Most intrinsic functions of Fortran are elemental, so exponentiating array x is done with just
x = exp(x)
No need for a triple loop as in C++.
(4) There are fast, flexible array intrinsic functions. If x is a matrix, one can compute the sum of all elements, the sum of each column, and the sum of each row with just
y = sum(x)
y = sum(x,dim=1)
y = sum(x,dim=2)
(5) One can work with arbitrary array sections with notation such as x(1:n1:2,:n2-1)
(6) One can define elemental functions and subroutines that operate on a scalar or an array of any dimension, just as the intrinsic functions do.
(7) Arrays of user-defined-types are convenient to work with. For example, given a data type
type
real
end type person
One can declare
type(person)
and then access the array of ages with just
players%age
In C/C++ one has built-in access only to the age of a single person with something like
players[0][0]%age
(8) Arrays can have a lower bound of 1 (the default) or any other integer. For many if not most calculations, 1-based indexing is more natural.
(9) The basic array syntax of
x(i,j,k)
in Fortran is more readable than the awkward
x[i][j][k]
of C/C++
Fortran rules!