Fortran
08 Nov 2019 - Richard Horridge
Object-oriented Fortran code to read arrays from a file
I have never had the pleasure to have written any significant programs in Fortran before this week.
As the oldest programming language still in use today (the second-oldest is my personal favourite, Lisp), it is tempting to ask how a language this old is still relevant today? First developed by IBM in the early 1950s, it quickly became adopted for scientific computation due to its powerful arrays and intrinsic use of complex numbers. While its syntax and semantics are probably offensive to engineers who have become used to Java and Python, at the time of introduction it reduced the amount of writing by 20 times compared to what was previously available!
Having written some COBOL before (I implemented an
MLP Neural Network in COBOL for an MSc project) some elements were
familiar, particularly the use of subroutines, rather than
functions, and the powerful Input/Output features available. It was
also nice to have an existing project to implement. I started with a
large MATLAB codebase which, following refactoring, I have begun to
implement in Fortran - MATLAB is largely implemented in
Fortran and its syntax is similar.
Modern Fortran has classes, generic functions and high-performance
capabilities and is extremely well suited to numeric
computation. While C was the first compiled language I learnt (and
still one of my favourites), it is less well suited to scientific
computation involving large arrays (and matrices), largely because
in C arrays are represented as pointers (memory addresses) and
function arguments may point to the same memory address. This
prevents some optimisations that Fortran is capable of, with
arrays as a first class data structure.
It's telling that the two oldest languages still in use are so
diametrically opposed. They both espouse different viewpoints:
Fortran aims to ease the writing of machine code, constantly
reminding the programmer that this is a computer that they are
talking to. Lisp will happily remove this notion entirely,
allowing an engineer to think only of operations on abstract data
(or code). They are both still extremely relevant and (I hope) will
remain relevant long after Java and Python are forgotten!
