08 Nov 2019 - Richard Horridge

2019-11-08 Fri 11:49


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!

Creative Commons License
This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License .