Lately I have been helping with the packaging of milancurcic’s datetime-fortran module (https://github.com/milancurcic/datetime-fortran). I needed it because I wanted to turn dates into indices.
I am taking a decade’s worth of Yahoo share data in CSV format, and stuffing it into a NetCDF file. It turns out that parsing the CSV file is relatively straightforward in Fortran. There’s no need for additional libraries. I chose NetCDF over HDF5 format because the latter was too much effort. Fortran’s interface to NetCDF has worked for me so far, although admittedly I haven’t played with the string functionality. That may prove to be more problematical.
One problem that faces many Fortran programmers is knowing array size at the outset. My solution so far is to overallocate the space I need, and, possibly, return an allocated array of the correct size with a copy of the data. It is not necessarily a general solution under all circumstances, but it is likely to be a good solution under most circumstances. Fortran will automatically deallocate the array for me (yeah Fortran!), and obviate the need to pass back array size explicitly.
I think the watchwords on Fortran are to use solutions which work, and avoid premature optimisation. I have said this before, and I’ll say it again: all programmers should be forced to work in Fortran for five years to teach them to solve problems in obvious and simple ways.
To give an example, a few years back I was working on some hydrocarbon allocation problems. The original code was written in Fortran. The data was in a file, for which the developers had a “mask”. Basically, the data file consisted of a number of arrays, with one number per line. So if you have arrays arr1, arr2, etc. you can read this file in using a single read statement: read(unit=whatever, fmt=*) arr1, arr2
That’s it! Done! Fortran just gives me that right out of the box. No other programming language is likely to be that simple.
I overheard an outside consultant talk about enhancing the system, probably using Java or somesuch. His solution was something along the lines “well we can always output extra values in XML”. Think how complicated that is! Now if I want to read in values I’m going to need an XML library.
I have found, too, especially when trying to wrangle data from third parties, that there’s rarely such a thing as “straightforward”. Murphy’s Law dictates that what can go wrong, will go wrong. Input data can have a lot of quirks to them. Even with high-level languages like Python, it seems that data providers devise obfuscations to subvert even good-quality libraries.
Fortran is usually more verbose than Python. It doesn’t necessarily “have” to be. You can let Fortran make assumptions about the types of your variables, but the general consensus is “don’t do that!”. So Fortran code might have something like real(kind=8), intent(out) :: foo
in a subroutine. This tells the compiler that you definitely want foo to be a 64-bit real. The “intent(out)” is completely optional, but it makes it clear to the compiler that foo is an output variable for the subroutine, and it automatically tells someone who is interested in your subroutine that it is an output. No-one is left in any doubt about what is expected to happen.
I think that, often, in the end, programming in Fortran is no more difficult or time-consuming than other languages. I wouldn’t necessarily use if for everything. Sometimes a bash script can be more effective. But do use a modern Fortran. Restricting yourself to Fortran-77 is making a rod for your own back.
People need to stop thinking that Fortran in terms of Fortran 77, and start thinking about more modern standards.