I’m in Fortran translation Hell

I learned a lot more low-level concepts because I started programming in Fortran77 before Java. It taught me about some key computer science subjects that were not taught in my CIS curriculum in school. So I have an affinity for the ancient language. But lately I’ve been translating some old Fortran77 code into Java to be used in an engineering application at work, and sometimes it makes me want to grind down my eyeballs with a Dremel tool.

It’s not so much the Fortran77 language as it is the programmer who was responsible for the code I’m working on translating right now. I have to cut the guy some slack because there were no such things as software engineers back in the 70’s. So we ended up with mathematicians, physicists, and engineers doing anything they could with the tools that had available without regard to the software developers who would come 30 years later to rehash their work into object-oriented languages.

Here is an example of one thing that is making my life miserable right now.

Fortran supports “GO TO” statements that allow you to arbitrarily “GO TO” any line of code in the program at any time. While it seems like this might simplify things at times, it NEVER EVER EVER DOES. What the “GO TO” allows is the ability for the programmer to break out of any loop at any time and choose a new point for the execution to flow to. This means that you can jump out of a loop and never return to the place you jumped from. If you happen to jump into another loop, so be it. Fortran will happliy continue along and start looping wherever the execution landed. This can make code almost impossible to understand. In fact, this is probably the source of the “spaghetti code” term.

Logic is sacrificed at some point in the whitespace between the typing of “GO” and “TO”.

If you are an OO programmer, there is no easy and straightforward way to break out of a loop and into another loop in the code, never to return to the previous loop. Even if you call another method to run some repetitious code, you’ll always return to the place where the original execution called the method. So if you want to make an OO language do something similar to what the “GO TO” does, you have to set up a way to break out of the loop immediately after the point where the “GO TO” occurs.

Here is another example of my dilemma. There is something in Fortran77 called an “arithmetic IF statement”. It goes something like this:

IF (VAL) 10, 20, 30

The value is evaluated. If “VAL” is less than 0, the execution will “GO TO” line 10 in the code. If “VAL” is = 0, “GO TO” line 20. And of course if “VAL” is greater than 0, “GO TO” line 30.

Horrible. Just horrible.

To add insult to injury, the programmer who wrote the program I’m currently working on favors the arithmetic IF statement over regular IF statements. So instead of writing

IF (X .EQ. 0) THEN
  CALL STUFF()
END

he writes

IF (X) 10, 20, 10
10 CALL STUFF()
20 CONTINUE

And he does this all the time. I’m going to go dunk my head in boiling pitch now.


3 Responses to “I’m in Fortran translation Hell”

  1. Lance Finney Says:

    Do we have to check you every day to make sure that you don’t have a Dremel on you?

  2. Matthew Taylor Says:

    If you hear a motorized whirring noise, please take appropriate action.

  3. M Easter Says:

    (a) Careful! I believe Dremel tools now come with onboard cameras (re: security)

    (b) I have seen Fortran long ago… To me, it has always been astounding that any program of a decent size actually worked. Or perhaps the delicate network of bugs managed to cancel each other out somehow.

    (c) If it is any solace, at least the syntax looks like the fashionable, dynamic languages. It’s like Ruby Lite: all the terseness, though without that “runtime security”.

Leave a Reply