"Samples in Fortran are not acceptable."

At the very least they acknowledge the existence of Fortran and, given the possibility that applicants would come up with projects in Fortran that conform to the other requirements, that Fortran has object-oriented features.


Not surprising. Why don’t we all apply and only show codes in Fortran?


Almost as disturbing is that the sample “should be object-oriented, contain five or more classes”. Not all good scientific software is object-oriented.

There are network effects in programming languages. It is easier to find C++ than Fortran programmers, so a group may standardize on C++, leading to fewer job openings for Fortran programmers, and less motivation for young people to learn it. One can try to break the cycle by making it easier to learn a language and giving it features not found in others.


This is almost certainly because they have unqualified people screening the samples. If you can’t find someone who can connect you to the hiring manager, don’t waste your time.


Unfortunately this is very, very, very, very difficult because there is a concomitant aspect with the vendors where the trends make them want to limit their investment up to some “ceiling” in Fortran compilers and with the support toward them. Parameterized derived type (PDT) is an example here.


I think ORNL believes that scientific computing will move away from Fortran, and it is hiring accordingly.

Jack Dongarra is a well-known figure in numerical linear algebra, involved in EISPACK, LINPACK, LAPACK, BLAS etc. He is affiliated with Oak Ridge and the University of Tennesee. (Oak Ridge is in Tennesee). He is one of the authors, along with UT colleagues, of a 2020 Lapack working note

Prospectus for the Next LAPACK and ScaLAPACK Libraries:
Basic ALgebra LIbraries for Sustainable Technology with
Interdisciplinary Collaboration (BALLISTIC)

BALLISTIC will be in C:

For historic reasons, the existing software base for Sca/LAPACK is
written in Fortran and uses archaic software engineering techniques.
Most scientific software written today is not based in Fortran, and a
recent study of programming languages ranks Fortran 38th, with the
top-3 programming languages listed as Python, Java, and C [129]. As
part of the BALLISTIC effort, we plan to develop a new prototype
library in C. We will involve the community at large (open source,
industry, users, contributors) in the design of the interfaces and the
library as a whole.

but Fortran compatible

We will follow language standards for all future development and will
strive to make all existing codes standards compliant. Specifically,
all C/C++ codes will be compliant with C11 (with C18 corrections) and
C++11 standards and their contemporary replacements, and all Fortran
interfaces will be compliant with Fortran 2003’s ISO C binding which
will serve the newer Fortran compilers.

It’s good that Fortran has recently climbed in the TIOBE rankings. The quote above shows how published language rankings influence the choice of programming language (although they use IEEE rankings, not TIOBE). Yes, LAPACK does use “archaic software engineering techniques”, because the people behind it have not really moved it beyond FORTRAN 77, although it is officially a Fortran 90 package. It uses fixed source form and no argument INTENTs, for example.

The classical FORTRAN libraries at Netlib were often developed at U.S. national labs. Modernization of those libraries is up to communities like this.


This job ad is bad in so many ways that the spitefulness about Fortran is just the cherry at the top.

Let’s see what they ask for…

  1. Contribute to the development of open source software on scientific projects and original research including scientific papers, reports and other artifacts.

So, they ask for a full-time scientist/expert in their respective field, conducting research, publishing, attending conferences, etc…

  1. Work closely with stakeholders to meet their software requirements, address bugs, and achieve their scientific goals.

So they ask for a manager. Someone who’ll spend their day between meetings with the stakeholders and coordinating a team of developers to address their needs.

  1. Deploy, maintain, and support web applications, servers, and cloud development platforms in support of scientific projects.

So they actually ask for a Full Stack Web Developer.

  1. Participate in the roadmap, vision, and strategy for enhancing software quality.

Nothing to see here… the expected HR gibberish between the important stuff.

  1. Mentor students to help them grow.

“Mentor”… hmmm yeah… we all know what this means… spend endless hours teaching Master and Ph.D. students how to code, the codebase, and finally end up writing most of their code…

  1. Participate in developing the strategic direction of research software engineering at ORNL.

I’d say this falls under the manager’s position, so I’ll count it as one with number 2.

In short, they combined four job positions under one. They ask for a superhuman, expert in all the above fields, working 24/7, ahh, and don’t forget, besides all, to share their hate about Fortran as well.

Let’s focus for a moment on this part about the at least 5 classes OOP sample code… Imagine for a moment that a meeting took place and experts discussed the merits of a good C++ programmer and how to peek one from the sea of incompetence. And they actually ended up with that number. Why 5 and not 4 or 6… and to think that they might have voted over this!

To conclude, the most worrisome is that you can just replace ORNL with many other companies or/and institutes alike. The number of identical ads I used to see back when I was at the job search for such a position is staggering.


Jack Dongarra et al. on Numerical Algorithms and Libraries at Exascale (2015)

Another relevant part of the HPC ecosystem that is being transformed as we move towards exascale includes programming languages, among which Fortran is finally being driven from the entrenched position it occupied in the last century. Complexities associated with today’s hardware call for complex software to drive it efficiently. Our interest is in lower-level tools for library-writing rather than high-level approaches such as PGAS languages and new execution models such as academia’s ParalleX or AMD’s Heterogeneous System Architecture. While we recognize object-oriented and co-array features of Fortran 2008, or the new support for parallelism in C and C++, at the library level we need to cater to a broad spectrum of languages and deliver the features and performance in a language-agnostic fashion. In that context, we foresee further expansion of support for heterogeneous platforms in standards such as OpenMP 4 and OpenACC 2. As noted above, the former made serious inroads into complex DAG scheduling and is on track to add task priorities in the next iteration; the latter continues to support ease of programming for GPU accelerators and to be inclusive of optimized system libraries. The main concerns are fragmentation of the community and the lack of a coherent path for porting important scientific codes from one standard to the other.


Very interesting points, but the really, really scary part - at least for me with respect to those I care about and should they decide to embark on such research software engineer careers - is there are quite a few such “superhumans” out there, who with their credentials and their work and more importantly publication history and open-source collaborations and contributions can easily get 3 or more other people to mark as “yes”, they meet those job requirements!

Now the absolute count of such people is miniscule relative to the 7.8+ billion global population, but it is an appreciable number compared to the number of such job positions available in desirable geographical/societal locations. So the institutes and companies can ratchet up the job requirements as much as they want.

Under the circumstances though, it’s also possible ORNL has already hired a candidate or have a candidate in mind but who needs a work visa/immigration paperwork and the posting is made to precisely match this candidate in order to absolutely minimize other applications that in turn help them complete the paperwork to allow the candidate get the desired immigration authorization.


So, they want to rewrite all the battle-tested Fortran libraries in a new language, using hardware specific, low-level techniques, so that they won’t be able to port them to other machines? Sounds like a recipe for a long lived project. /s


Dongarra is probably just writing the words he thinks finding agencies want to see. The only other conclusion is that he has “lost it” in terms of computing. (He is quite old, so some consideration is reasonable). The original posting should go down in some hall-of-shame. They are basically asking for code that is unreadable and impossible to understand or debug. Oh, yeah, and C++ is also a language from the “last century”. If they convert everything to Python, they will need twice as much hardware to overcome the inefficiency. Maybe us vendors should encourage that.


No, this is just discriminating and as such unacceptable. The head behind this takes full responsibility. The problem is this (quote):

“Experience using multiple languages, including the following: C/C++, Java, JavaScript, Python. Applicants with experience only in Fortran will not be considered.”

The first sentence does already describe the requirements for applicants: “Experience using multiple languages,…”. The second sentence is the problem and should not be ignored: It does not address technology but human beings (pure Fortran programmers). This sentence is completely unnecessary to further describe the requirements for applicants to the job because the requirement for using multiple languages is already mentioned. This second sentence is not just addressing to the Fortran programming language itself but clearly and unmistakable to discriminate Fortran programmers (human beings).

I am a german-located developer and hope that someone else here has the courage to inform authorities at Oak Ridge National Laboratory about this and does give some feedback here. Else I will do that myself. This is a shame for that institute.

Michael Siehl


Chombo - Software for Adaptive Solutions of Partial Differential Equations, a project from another U.S. national lab, LBNL, is described on GitHub as “fortran-free”. OK, that is concise, if not tactful. The Copyright.txt saying
Let this be the first nail in the coffin of Fortran
suggests that the decision to make the project independent of Fortran was not made entirely on technical grounds. An earlier version

include[d] a system for writing dimension-independent FORTRAN which we call “Chombo Fortran”. Fortran subroutines are used for the most compute-intensive parts of Chombo applications because they produce faster results.

A fork of Chombo that still uses Fortran is here.


This description provides some hints as to why they might have decided to drop Fortran in the latest version:

  • Chombo Fortran

    • Provides a less error-prone interface for mixed language programming.
    • Provides a dimension-independent syntax for Fortran.
      • 1, 2, and 3 dimensional simulations can call the same Fortran subroutines.
      • This eliminates the software maintenance nightmare of maintaining separate Fortran cores for each dimension.
    • Fortran 77 and the prototypes headers to call it are generated from Chombo Fortran files.
    • OpenMP hooks and other performance optimizations can be added automatically into Fortran subroutines
1 Like

Wow… Well, there are very good technical and social reasons to ditch Fortran, no doubt. I also think all of this can be fixed, and I usually tell managers to wait 3 years (I was telling them 3 to 5 years about 2 years ago). We have made great progress in the last 2 years, but our goal should be in the next 3 years to completely fix the tooling and community around Fortran and bring in on par with other modern languages.


Bike shedding over a technology that is robust and proven like Fortran suggests greater management problems at that location.

I know C++ has improved since 2011, but what is the backwards compatibility record with modern C++? How much breakage will result as newer versions are used?

A thought came to me recently:
as far as I know, there are currently three new Fortran compilers in development: Flang, Intel ifx, LFortran. Isn’t it a lot for a language that some people see as doomed to disappear? Three seems too many. How many languages have three new compilers simultaneously developed?


Of course. And you just need to look at the Compilers page to see how many active compilers there are. I know only of few other languages that have that.

I suspect that people who don’t work close to Fortran don’t know where to look to find Fortran.


Three seems too many. How many languages have three new compilers simultaneously developed?

Common Lisp has at least 4 open source implementations as well as a few proprietary ones. Prolog as at least 4 open source of the top of my head as well, along with closed source options. C has a number of compilers if we are talking about c89. I only know of 2 open source C99+ compilers; same holds for C++

D has 3 compilers now – GDC (integrated into GCC), LDC (integrated into LLVM), and the reference DMD (Digital Mars D Compiler).

It appears I’m mistaken. The D Language community continues to develop the front end, and provides instructions on how to build with various versions of LLVM here. I could have sworn reading that D will be integrated into LLVM “soon” but cannot find that info.


Just for completeness:
You don’t have to build from source to use LDC – there are binaries available: