In my short 9 years of being a scientist/programmer I have learned a lot. I feel that the journey of scientific programming into High Performance Computing (HPC) is a common one. In my current job, my collaborators that are contributing to a weather model none of them are climate scientists nor computer scientists by education.

We are a range of physicists, mathematicians, engineers, chemists, etc. who have learned how to code in the academic fashion: “You need to write this code to write a paper so that it can get published so that you can then graduate.”

This is the domain of academic driven software development. It is mostly a means to an end that ends up growing beyond a certain amount of control and becomes its own entity (almost sentient!).

I have had the fortune of working with many people across my years as a programmer that have taught me the good, the bad, the ugly, and the awful in the arts of writing good code.

In this blog I will be talking about experiences I’ve learned throughout my short life as a programmer. Mostly talking about maintaining and modernizing legacy, scientific code; HPC and performance/portability for accelerator architectures; developing reusable and extendable libraries for convenient stuff; and my tips and tricks for doing some common tasks I’ve encountered, like how to set up a midly sane CMake build system, etc.

On programming languages#

I am familiar with multiple programming languages and, as any good software engineer, I have strong opinions about certain languages and how they do things. Let’s get some of these out of the way before we do anything else further in this blog.

I am familiar with:

  • Python: Basic, functional but I wouldn’t consider myself dangerous with Python. I use vim to write code so spaces and tabs are the bane of my existence
  • Julia: Basic but was advanced at some point in time. I helped coauthor a paper using Julia to write quantum chemistry code. Haven’t touched it in a while now.
  • C++: I have written thousands of lines of C++ most of them were not great. The problem with C++ is that it is vast. I am familiar with many of the basic concepts and how to use classes, inheritance, templates, shared pointers, unique pointers etc. however, if you ask me what is new in the latest standard? no idea.
  • C: Mostly have used it to write interfaces as the lingua franca to communicate between languages. If I had to choose, I’d write C++, not C
  • Bash: I am dangerous with bash.
  • Fortran: I am as familiar with Fortran as I am with C++, which makes me more dangerous in Fortran since it is a smaller language.

Fortran#

Since leaving my position as a postdoc (where I wrote the most C++ in my life) I have been diving deeper into the Fortran ocean. Since I learned that I had gotten the position I started spending more time in it, since I knew that I was going to be working with climate and weather codes, which are still mostly written in Fortran and the push to rewrite things into C++ has not been as successfull.

Therefore, most of this blog will be talking about Fortran but still with some examples in other languages like C/C++ and Python and Julia.

The main thesis statement of this blog is the following: It is easier for non-computer scientists to write fast code in Fortran than it is to write it in C++.

My supporting statements are:

  • Fortran is a much smaller language. In C++ there’s a myriad ways to do the same thing and some are much better than others.
  • Fortran allocatable arrays are memory safe. It is difficult to introduce memory leaks in Fortran unless you’re doing something weird.
  • Fortran arrays are first-class citizens and are very easy to use and manipulate
  • Fortran was designed for numerical computing; C++ is a general purpose language

My counter arguments are:

  • Fortran is a much smaller language. The standard library in C++ provides a lot of finely tuned functionality that you have to develop yourself in Fortran
  • C++ has much better compatibility with external tools due to non compiler specific headers, as opposed to Fortran modules
  • C++ has much more powerful object oriented capabilities that allow you to produce simpler, cleaner interfaces

General conclusions#

There’s a language for every task. You wouldn’t use python to write an application that should scale on a full machine with thousands of nodes.

You wouldn’t write a plotting library in Fortran.

C++ is gigantic in a way that you can really write anything in C++. Which makes it rather complex.

In the end choosing a language is like choosing a knife for your personal kitchen. You might know that the Shun knives are great - but you might like Global. That’s in the end how it is.