At the last monthly call we touched briefly upon the “goal of Fortran”. Perhaps I can use this thread to elaborate my view further.
In fact several mature scientific libraries exist in Fortran. The most notable examples are
Unfortunately, the ones that are actively maintained (NAG, IMSL) are not open source. HSL is free for non-commercial use, but obtaining and using the code is not very user-friendly. The SLATEC and NSWC on the other hand are Fortran 77 style codes with old-fashioned calling sequences and lacking modern documentation. The GNU Scientific Library you mention was in fact developed as a modern replacement to SLATEC.
There are hundreds more of specialist packages, if you think about all the codes available on netlib and GAMS.
Since Fortran users are scientists and engineers, most of them lack the training in software engineering and web development, which are necessary to set up an accesible library. Thinking of the era of old mainframe computers, not everyone had a course in numerical analysis or even the opportunity to work with a computer. It would have made sense to pay a professional provide you with the routines needed to solve your computational problem. At the same time new programs (programming languages) such as MATLAB and Octave were developed, to give people access to numerical tools without having to learn Fortran.
Cleve Moler wrote about this in his blog:
In the 1970s and early 1980s, while I was working on the LINPACK and EISPACK projects that I discussed in two previous posts, I was a Professor of Mathematics and then of Computer Science at the University of New Mexico in Albuquerque. I was teaching courses in Linear Algebra and Numerical Analysis. I wanted my students to have easy access to LINPACK and EISPACK without writing Fortran programs. By “easy access” I meant not going through the remote batch processing and the repeated edit-compile-link-load-execute process that was ordinarily required on the campus central mainframe computer.
(Thanks to @urbanjost, we still have a copy of an old version of MATLAB.)
A similar motivation can be found from the Octave developers:
Octave was originally conceived (in about 1988) to be companion software for an undergraduate-level textbook on chemical reactor design being written by James B. Rawlings of the University of Wisconsin-Madison and John G. Ekerdt of the University of Texas. We originally envisioned some very specialized tools for the solution of chemical reactor design problems. Later, after seeing the limitations of that approach, we opted to attempt to build a much more flexible tool.
There were still some people who said that we should just be using Fortran instead, because it is the computer language of engineering, but every time we had tried that, the students spent far too much time trying to figure out why their Fortran code failed and not enough time learning about chemical engineering. We believed that with an interactive environment like Octave, most students would be able to pick up the basics quickly, and begin using it confidently in just a few hours.
We could say that at this point Fortran was already losing users. For simple scientific calculations, interactive usage is much more straightforward than the Fortran development cycle. Thinking of F77, without modules, and without a good packaging solution, it is painstaking process to get all your calls correct. Especially, when you are doing all your work through a tiny terminal.
So at this point we could say Fortran was already becoming a niche language for HPC users, and falling out of favor for data analysis and everyday scientific calculations. One of the places were Fortran was in everyday use for statistics, data analysis, and plotting, was at CERN in the form of the the CERN Program Library. This was until it was finally superseded by ROOT (a program in C++) in 2003.
Concerning strategy, on top of what @certik wrote, with respect to stdlib, I think it is most important we define interfaces for the common scientific procedures we would like to see (essentially the stuff in NAG and IMSL).
Then it is just a matter of time to consolidate and refactor the publicly available Fortran codes which fit into such a scientific library (the Fortran codes which are wrapped in SciPy, SLATEC, other codes from netlib, etc.). This would be the free stdlib.
I used the word refactor, because I have the experience that it can be easier to generate a robust Fortran wrapper in Python, than it is to provide the same old Fortran package in modern Fortran. This is because Fortran, compared to Python, lacks assertions, exception handling, positional and keyword arguments, introspection, etc. Ironically, the old F77 style interfaces with explicit length array arguments and work arrays are easier to wrap, than some modern Fortran codes that utilize allocatable and assumed shape arrays, derived types, etc.
If we can bring stdlib far enough ahead, hopefully then organizations such as Intel, NAG, and IMSL would decide to offer versions of their own routine libraries, conforming to the stdlib interface. This can be done very elegantly using sub-modules. In fact we could even take a shortcut, and have back ends based upon GSL or Boost C++ libraries.
But agreeing upon on a sensible Fortran library API is the first and most crucial step.
