Salaries for software engineers at a US national labs like LANL don't deviate far from the $100k range [1]. For many projects, a security clearance and on-site presence are required. Add to that the requirement to train and use Fortran (old and new), the job proposition is only looking good to (1) people who love the problem domain (e.g., nuclear stockpile stewardship), (2) people who are specialized scientists who moonlight as programmers, or (3) people who simply like government lab environments (stability, science, ...).

[1] A SWE4 (BS + 12 YoE) has a pay scale of $109k - $182k and requires a Q clearance (top secret for nuclear): https://lanl.jobs/search/jobdetails/senior-software-applicat...

If you're a top-rate software engineer, you're not going to choose a career path that will trap you in some deprecated technology.

The challenge isn't that people can't learn it, it's that they don't want to because it's a bad career move.

This isn't true.

Enough of good programmers choose unpopular languages, and for different reasons. Some genuinely find particular aspects of the chosen language appealing, and since they are in general good programmers they don't have a fear of unemployment or the pressure to build their career -- they've already established themselves in their field and don't need to reassert their skills and knowledge.

Others may opportunistically choose a new, but still unpopular technology, sometimes because other good programmers seem to have chosen it, other times because they may hope to gain more popularity / acclaim, which is easier to do in a new, and especially in a small field.

Furthermore, it just so happened that popular technologies in the industry today are all kinds of bad. Just of sheer desperation / disdain to a particular group of related technologies one may want to try to switch to a niche technology that seems to go against the mainstream.

---

However, in all those cases, there must be something "interesting" going on for the technology in question. I don't know enough of Fortran to claim there's nothing "interesting" going on for it, but it's possible that there isn't. In which case, there won't be an incentive for good programmers to choose it over similar technology that has that glimmer of hope that it's going to be so much better.

> I don't know enough of Fortran to claim there's nothing "interesting" going on for it

You mean in the language itself or its applications. Honestly I’ve heard about a lot of really cool things written in Fortran. Honestly, I wouldn’t mind learning it, but I’m far from a “ top-rate computer scientist” so no Ike using Fortran would be interested in me.

All good stuff I've ever heard about Fortran could be summed up as "it's easier to write optimizing compilers for it", which was probably a claim made more than ten years ago based on an interview with someone who worked for IBM over twenty years ago on Fortran compiler.

Suppose this was the only really good thing going on for it... well, this wouldn't attract a lot of people. Also, I'm not sure Fortran can boast to be the easiest language for optimization. I believe the statement was made in the context of comparing it to C, in which case, it's not such a high bar.

I've been out of grad school for a bit now, but 10 years ago is about right. There were a lot of things being published about compilers that might have well been direct ports of papers written in the 70s, "now for JITs." And honestly, if you read some of those papers from the 70s about automatic parallelization and such, it was pretty freakin' cool. And there were memory guarantees in Fortran that were not present in C that made it non-applicable. Java had most/all of those guarantees, which is what I think brought about their revival. That's probably not the whole explanation, as I'm not sure why it took Java so long (these were 2010+ papers, 15+ years after Java came out).

The very first optimizing compiler was written in Fortran, to compile Fortran. I think this was the 60s.

The use of pointers in a language vastly complicates the task of optimization. From Fran Allen, a compiler researcher and co-inventor of SSA,

By 1960, we had a long list of amazing languages: Lisp, APL, Fortran, COBOL, Algol 60. These are higher-level than C. We have seriously regressed, since C developed. C has destroyed our ability to advance the state of the art in automatic optimization, automatic parallelization, automatic mapping of a high-level language to the machine. This is one of the reasons compilers are basically not taught much anymore in the colleges and universities.

> If you're a top-rate software engineer, you're not going to choose a career path that will trap you in some deprecated technology.

Which is kinda good, to be honest. Long-term Fortran projects and the like don't deal with the usual FAANG-type career-oriented churn that well, that mirrors the same problems you have in academia-oriented libraries where you get maintenance gaps when graduate students leave.

I would have assumed that the best engineers are not afraid of being “trapped” by a specific technology. That seems like a very surface level concern to me.

> some deprecated technology

In numbers, IT jobs are dominated by social media companies, and companies selling ads and services on the web and via mobile apps. But I don't think these areas of applications should define what is or isn't deprecated technology for e.g. nuclear simulations, and weather and climate forecasts.

Fortran is bad for implementing web services. But it doesn't make popular web service technologies good for weather forecasting, either.

Yeah learning a new JS framework every three months is much more rewarding!

Financially, it is.

While I agree that a computer scientist should be able to pick up any language with a bit of training, to be effective in using it, it takes – sometimes – years of continued use. That's a steep investment for any company/lab.

Years is an exaggeration. I happened to ride the popularity wave of both Go and Rust at their respective moments. I've seen a lot of programmers, good to mediocre-bad learning a new language on the job. The range is between a month and three months maybe. It's really not that big of a deal.

> Years is an exaggeration

Not necessarily when it's not your job, but it depends on what level of comfort / ease we are talking about.

A relative who is a physicist and who started with Fortran recently switched to Python. They told me it took them around 3 years to be as comfortable as before.

Now, I suspect they were very comfortable with Fortran to begin with, and if they programmed a significant amount of time everyday, they would have been up to speed way faster.

(They also said they would not go back to Fortran)

My wife is an "RSE" (research software engineer), she's an MD by training, but doing some programming for research. She's been in this role for about two years now, and she did maybe another two years of Python programming prior to that in a similar role.

She still doesn't feel comfortable with Python (or any language) and often needs guidance / help. Mostly because in this role, the amount of programming is really minuscule, and the expectation isn't that the programmer develops a useful application or library well-integrated into the larger ecosystem of applications or libraries. Rather it's that some research can sift through the data they've generated and publish on that.

The instances of "re-education" I was talking about were quite different: those were "programmer-first" people. In this capacity, they might write in a month more code than what what my wife wrote over the last four years, they are also expected to build a lot more complex (in terms of organization and integration) software.

I don't consider RSEs or similar roles to be professional programmers. These people typically have terminatory degrees in fields other than CS, but often no formal training in CS. They also rarely see their own goals in becoming as good of a programmer as they can, their evaluation is typically based on results that programming might help to bring about, but, in principle, isn't really necessary for. Sort of how you wouldn't call every programmer a "professional mathematician", even though writing programs is a kind of math, as is eg. checking out customers at the supermarket.

So, while someone like that might need years to adjust to a new language, OP seemed to have in mind professional good programmers. I think they even had another bullet point for hybrid scientist-programmers.

While I think you're correct that goals and roles may be different, on average, for the scientist-turned-programmer trajectory, there are plenty of RSEs who come from the opposite direction, i.e. strong programming background, but picks up the problem domain on the job.

Source: am RSE. And I will also say, a few of the scientists I support are among the best software engineers I have ever worked with, despite caring about code only insofar as it can help answer useful questions.

> A relative who is a physicist and who started with Fortran recently switched to Python.

Fortran is considerably simpler than Python, though. No metaprogramming. No functional programming. No objects. Etc.

Fortran is very simple though, more like Go or Java than Haskell. A C developer could pick it up in a week or so just reading the ISO spec, someone else might take like three weeks?

It's basically C with nicer syntax, and some QoL features.

I agree, Fortran is easy to learn, and it's a pretty small language so you can keep it all in your head. The part about Fortran that I find hard is the "culture" around it. There are styles of programming in Fortran that just don't work with my brain. Just like the "Java culture" of extreme abstraction (i.e FactoryFactoryBuilderHelper classes) bothers me too.

I can start a fresh Fortran program and write it out pretty quickly (though I do miss native dictionaries), but when I have to collaborate with an old-school Fortran programmer (especially one trained on FORTRAN 77) it's pretty tough for me. I have to reprogram my brain to think in that style/culture.

I tend to do most of my high performance numerical stuff in Numpy since it defers to the Fortran libraries for the hard stuff. I haven't found any properly written vectorized code get bottlenecked in the interpreter.

Fortran is simple enough to be used by dumb physicists. At its core it is a standard procedural language, like C with a lot less footguns and much more user-friendly. Its object-oriented parts have some strange syntax, but are otherwise unsurprising. There isn’t any step like when starting something like Lisp or Haskell.

It would definitely not take years to get on top of it for anyone who knows a bit of programming.

It's not about learning Fortran being hard, obviously if you're good you can acquire any language, especially in a paradigm you already know anyway, but why ?

That's the thing for these "top-rate" posts, you need to sell the candidates on why they want to take your offer, not some other role they could have. Yes, one option is to "just" pay them a tremendous amount of money, but remember you're competing with the banks who have the same strategy and their whole business is making money. So that would be very expensive.

Instead it makes sense to compete on other considerations. Candidate doesn't like to work in the office? No problem. Stay where you are, work for us remotely. Or maybe they'd like to move their grand parents and extended family to your country? You could make that happen. Or could you? Do you think the US Federal Government will accept "We need to naturalize these sixteen random people, immediately to get one Fortran programmer" ?

And the choice of language is one of those other considerations. To a first approximation nobody is more keen to take your offer because they get to write Fortran.

Hiring Fortran programmers is risky because there's so few and those that claim to know it might either be exaggerating or simply not good at it. It's not just the language, anyone can learn the syntax. It's making sure that whoever you bring in can actually do the job

The "Hiring Fortran programmers is risky" argument is incorrect. This is, in fact, the whole point of Fortran, that anyone as dumb as a rock "would" (not "could" or "might") write performant code. There is currently no other language that can achieve this. Any other language claiming this capability is essentially recreating Fortran (perhaps with a slightly different syntax). Fortran Standard has been pursuing this sole goal for 70 years and has become extremely good at it. Your argument applies very well to C++, though. But it's not too hard to catch a novice there, either.