Complaining about compilers
Like many astronomers, I have written or acquired a small set of Fortran tasks to help in data analysis. All these programs ran fine on the machines I used at Harvard (DEC Alphas), but today I tried to recompile one of them on my Linux machine at the office. Among the many issues with g77 on Linux: 1) It doesn't like the "encode" command, 2) It doesn't support some of the options on the "open" command, 3) It didn't like one of my subroutine names because it has been reserved as an as-yet-unused intrinsic, 4) It complains that I (intentionally) modified a loop variable within a loop, and 5) It doesn't seem to deal with units defined as FORTnn environment variables. After much futzing, I got the program to compile without error, but the algorithm didn't work, even though the program compiled and ran without error on the same data on the Alphas (which I verified today).
Okay, I admit that some of the code is antiquated, and my coding technique is questionable. But that's no excuse for the multiple errors I encountered with g77 under Linux. If code compiles and runs properly on one platform, it ought to work on another platform with another compiler, without reediting.
Okay, I admit that some of the code is antiquated, and my coding technique is questionable. But that's no excuse for the multiple errors I encountered with g77 under Linux. If code compiles and runs properly on one platform, it ought to work on another platform with another compiler, without reediting.
4 Comments:
I haven't written anything in Fortran in years, and I hope I never have to do so again.
Indeed, DEC Fortran has quite a few features that aren't considered "standard", although I don't know what's standard and what's not. And it's possible that I'm mixing f77 and f90, although the g77 manual claims to support a lot of f90 (and DEC Fortran) extensions.
Anne: What didn't you like about Fortran? Other than fixed-form format (and some unknown compatibility issue I'm facing), it's pretty straightforward. And even fixed-form format isn't compulsory under f90 (and some f77) compilers.
Which is why java can be so nice to program in for a lot of things. You don't have to worry about things that are too low level and for most purposes the performance is adequate. The built-in class library is pretty comprehensive for most basic things and there's a lot of other libraries out there. But then come deployment time you find that you've got to lug around this huge runtime all over the place since it really just simulates cross-platformness by making you code to its own platform. I'm eagerly waiting for GCJ, which can compile java directly to object code, to finally become usable enough. But I guess java wouldn't be all that great for heavy numeric work anyway since it has no operator overloading.
"The good news is that in 1995 we will have a good operating system and programming language; the bad news is that they will be Unix and C++."
-- Richard P. Gabriel in 1991
Sadly for the software world I think that's still true for 2005.
I once had to find a bug in a Fortran program that was as long as a book. The program would compile fine, but when run it crashed the server. I tried debugging it, but that crashed too. The sysadmin had to hard reset the machine! This thing took a while to compile, too. It took me so long to find this stupid bug, and what was it? One space! ONE SPACE in the entire program!
Post a Comment
<< Home