 |
In the eighties, science undergraduates like me took a course in structured programming at the computer science department. My Alma Mater taught Algol 68; needless to say that Algol 68 is perfectly suited for teaching structured programming, a skill that serves a lifetime. However, elsewhere in the science and engineering departments staff would discourage using such language for production work. At the time, the dominant workhorse for serious numerical work was Fortran.
Fortran is one of the few languages whose target audience are engineers and scientists. It essentially is a tremendous calculator with general purpose stuff bolted on. The reason it looks like a general purpose language, may be because at the time there were far less specialised programming languages around than today. For a long time your choices were limited to Fortran, COBOL or maybe something esoteric like ALGOL.
Sure, Fortran is being revised up to this day but this is debated as new features may break vintage code or may make it approximate existing languages that have already drawn people away from Fortran. For many new science or machine learning projects where raw speed is not the decisive criterion, people choose newcomers like Python. I myself use Python nowadays.
In the old days the reasons to use Fortran, even against your will, were compelling. Being geared towards computation, it could easily be learned on-the-job by science or engineering students. Computing resources were expensive so users had to pay for using them, and Fortran squeezed most results out of your limited budget. It was ubiquitous and portable, therefore a large amount of well-tested Fortran applications and libraries existed. On supercomputers, it was your only option to write portable software. In short, your productivity and cooperability depended on you embracing this language.
At age 65, Fortran still ranks among the fast languages around for numerical applications. Because it was popular and important, Fortran has solid optimising compilers that produce quality code. One reason for vintage Fortran's speed was that mere programmers were not allowed to manipulate pointers, which enabled an optimiser to do more.
I have vintage Fortran code on the shelf that I could have translated into C using a quality tool like f2c. However, f2c does not meet my need for multi-precision types, and adheres to 1980's C standards. Hence I cheerfully wrote VIF (VIntage Fortran). It is a straightforward gcc front-end that translates most of Fortran IV/66/77 into C99 exploiting gcc extensions to improve efficiency, at the cost of eliminating a few rarely used statements like ENTRY that have no direct C equivalent. Hence VIF compiles most but not all source code, but can compile large packages like LAPACK (the F77 source code, obviously) into its library.
VIF is probably the only vintage Fortran implementation with REAL*32 and corresponding COMPLEX*64 types, sufficient to handle many multi-precision applications. VIF comes with a mathematical library built from vintage, publicly available source code. If you would want to give VIF a whirl and experience the joy and pain of programming in vintage Fortran, you can download it here. Do keep in mind however that VIF is an experimental compiler, not meant as a production tool. For production work, consider for instance GNU Fortran.
Frankly, I do not code that much Fortran these days, but for my daughter's high school maths graduation project on the life and work of Katherine Johnson, I wrote a simple demo for integrating differential equations using Euler's method to simulate LEM landings on the Moon. A verbose, old-school VIF listing of this program can be found here. It is priceless to see the face of a child when this space-age programming example actually succeeds in landing a LEM safely on the Moon's surface.
Throughout my career there have constantly been prophecies on the forthcoming demise of Fortran. Yet it is still here, and not only because some years ago NASA was looking for a Fortran guru to work on vintage software from the Voyager project, or reaching out to coders to optimise Fortran code for the Pleiades supercomputer.
Most likely the reason Fortran keeps appearing in programming language rankings is its continuing use in heavy number crunching. Who would consider investing resources in rewriting and retesting zillions of lines of mature production code unless there is a good reason to do so? Innovation takes more than replacing that what works well with something new.
Supposedly Fortran will be around as long as the immense body of code written in it, remains in use. Only time will tell Fortran's future, though I am convinced that it will survive at least me.
|
|
© 2002-2024 J.M. van der Veer (jmvdveer@xs4all.nl)
|
