Hacker News Reader

I am one of the co-founders of the fortran-lang effort. I did it while I was at LANL, where I worked as a scientist for almost 9 years. I think the report is overly pessimistic. Here is my full reply on the report: https://fortran-lang.discourse.group/t/an-evaluation-of-risk....

And yet, we now a compiler (Codon) that can compile Python into Fortran code, also allowing direct use of LLVM IR and ability to import C (and Fortran?) libraries.

Perhaps, interoperability is the way forward.

Yes, I lead the development of these two compilers:

https://lpython.org/ https://lfortran.org/

LPython compiles Python at the Fortran speed, since both compilers share the same internals.

So, I have a question (I didn't real the LANL paper, save for the highlights above, but I did read your initial post that you linked to).

And this isn't meant as some kind of bait, just honest intellectual curiosity (its the internet so you can't see how it presented, just read the raw words).

Simply, why is it important for Fortran to survive in this space? Why not let the field move on? Why fight this fight?

BLAS/LAPACK (fortran blobs) are the miracle that all AI relies on (to my understanding). I hope we keep it around and maintained.

I wonder why the cascaded triple for loop for GEMM is not just hardcoded in assembly for each architecture. And while we are at it, why is MKL > 5GB again?

Does this address your MKL question?[1] If so, sounds like we're two of today's lucky 10,000![0] Although for this esoterica, I'd probably reduce that to 10.

[0] https://xkcd.com/1053/

[1] https://community.intel.com/t5/Intel-oneAPI-Math-Kernel-Libr...

Most decent BLAS implementations use some variation of the kernels in K. Goto et al. "Anatomy of High-Performance Matrix Multiplication" written in assembly.

It's a great question. I think we answered it in one of our initial blog posts when we started LFortran:

https://lfortran.org/blog/2019/05/why-to-use-fortran-for-new...

Let me know if you have any follow up questions.

> big iron imperative language offers over the dozens of other superficially similar choices

Given the capabilities of modern machines and the fact that non-homogenous hardware (GPUs, different processors like in Apple Silicon) is back, the "winning" strategy is to have high-level scripting languages where you can ignore most of the details, which call into hyper-optimized, high performance libraries. For instance, when you're using Scipy, you call into Fortran and C almost interchangeably.

Since most likely you aren't writing full programs in the low-level language, it doesn't need to be a general-purpose language offering the same affordances, say, C++ is supposed to provide.

For numerical/scientific code, Fortran is much, much easier to use, especially for people whose background isn't computer science. Being able to write your code in terms of matrices and arrays rather than "pointer to const restrict" is a godsend when you're programming what is often very difficult mathematical code. When compared to modern C or C++ you won't get any advantage in terms of performance, but you don't lose much either, and in return you get to use a language that's much more suited to the task.

The historical Achilles' heel of Fortran is that it's kind of awkward as a general-purpose language, but that's negated by the "compiled core, interpreted shell" approach that's dominant these days.

(I should preface this by saying that my claims are all based on what I see in a specific scientific community and US laboratory environment. I can't say for sure my observations are true more generally.)

I think what you say is true in principle, basically on all counts, but Fortran's niche that its advantages serve best has been continually eaten away at by the Python/C++ combination.

The "I don't know pointers" crowd steers toward Python, and the "I care about CPU cycles" crowd steers toward C++, and that relationship is symbiotic.

Julia promised to be a general-purpose language, both as fast (or faster) than Fortran/C++ and as easy (or easier) than Fortran/Python. But it doesn't seem to have panned out as they'd perhaps have hoped.

Looking at Julia Computing industry partners, it isn't that bad.

Fortran still has a big fanbase and people actively fighting to keep it alive and thriving as much as possible. Maybe the crown will remain with C++ (in terms of fast languages), and maybe Rust will eat some of its lunch, but there seems to be a resurgence in the Fortran community to make sure it remains an important language in this space.

Julia has something similar but to a lesser degree. Its main problem has been the developer experience - the latencies (slowly getting better), lack of a great editor/LSP experience (the VS Code plugin is decent, but not yet great), lack of accessible how-to resources (people are starting to write more of these), and things like that.

I don't think Julia has been around quite long enough to make that statement yet.

I've just noticed it's now available on the system I work with, which puts it in the frame for a possible (probably far out still)future move for a massive C/Fortran codebase I maintain.

My general default if I'm going to update something is C++, but from what I see of Julia it's at least worth a look.

How has it “not panned out”? Julia has been in a useable state only for a few years, and is still rapidly developing. Prior to Julia 1.0, I would have said Fortran (which I have 15 years experience with) was the most productive language for scientific computing. Today, Julia is, by a wide margin. In fact, our benchmarks show Julia matching or beating Fortran’s performance, to say nothing of the mich increased flexibility.

In my experience "very difficult mathematical code" stems from employing little or no abstraction of the problem domain, mashing together numerical algorithms with physics formula. Using Fortran is IMO as much a prerequisite as a result of this.

I fully agree with you that scripting languages are a great fit for scientific computing. But I just don't see how this is a case for Fortran.

R or Python are still much easier to use and give you the same access to high-performance numerical accelerators via BLAS/LAPACK backends. And if you need a low-level language (e.g when developing an optimised routine that solves a specific problem), I would use a high-performance widely supported systems programming language like C++ or Rust.

Fortran seems to be around mostly for legacy reasons. And I am not sure that legacy considerations alone make a good foundation.

BLAS/LAPACK are written in fortran was the point I think. There are eigen and nalgebra certainly, but neither exports as cleanly to python, and neither is significantly (if at all) faster.

CuBLAS on the other hand makes a lot of sense to use from python if you have the right hardware.

The reference implementation of BLAS that you should absolutely not use is written in Fortran. The actual implementations are written in C/C++/ASM.

That's not to say you should use C yourself, memory management is a lot nicer in Fortran, for multidimensional arrays. You can stack allocate arrays inside functions and modern fortran has move semantics. Arrays are contiguous even if they have multiple index. It's generally a nice language for math, has good C API integration (both as caller and callee) and compiles down to small libraries without runtimes.

Thanks! I did not most any of that. Except for that it is good at math.

Loops in Python are excruciatingly slow, for no reason. Some algorithms are naturally written using loops, and Python makes this very uncomfortable, forcing you to rewrite your algorithm in a non-natural way. I hate writing numerical code in Python due to that; it just feels uncomfortable.

For scientific computation I just need multi-dimensional arrays of floats and fast loops. Fortran has both of these things natively. Python has neither.

I prefer vector types for this kind of stuff, as they are more compact than loops and naturally lend themselves to auto-vectorisation. In the end it comes down to the programming style preference.

A lot of the code used in scientific computing cannot be vectorized because the latter loop is dependent on the former loop (like time stepping in a simulation). It’s not really a programming style preference.

C++ and Rust don’t really have good semantics for scientific computing (linear algebra). They’re great for many other domains like “system’s programming”, where Fortran doesn’t compete, of course. The only language that’s similarly (in fact, more) expressive as Fortran for scientific computing today, as well as holding up for performance, is Julia

> the "winning" strategy is to have high-level scripting languages where you can ignore most of the details

From personal experience, I don't believe this works in practice. Invariably, some level of logic is implemented in said scripting language, and it becomes a huge bottleneck. Counterintuitively, when you have a central thread dolling out work to many subroutines, the performance of that thread becomes more critical as opposed to less.

"Invariably, some level of logic is implemented in said scripting language, and it becomes a huge bottleneck. "

Not necessarily and if it does, then the solution is to add that logic into the low level libary. So yes, you need at least one guy who can do this.

At that point, you’re not really using the high level language.

If you aren't using the scripting language enough for it to get in the way, you're probably not using it enough for it to make things easier either.

Just to be clear, I'm not saying it's impossible to strike the balance where it makes sense. I'm just saying I've yet to see it work, and I would, therefore, not assume such a balance is given by default, or even easy to achieve.

I agree with you. There’s also the additional cost of maintaining more than one language which makes the balance that much harder to do. I could see utility in the high level language to do something with the result if it’s not computationally intensive.

The theory is that 99% of the code is in the high level language, and 1% is in the low level language.

In my experience, that means that 80-90% of the developer effort goes into getting the FFI bindings to not be terrible. (In fairness to things like python, most of my FFI experience is with Java, which is notoriously bad at such things)

Have a look how games work. They are very performance critical - you have to calculate your simulation and draw it 60 times per second. That only works, if you have high performance low level libs. It is very common to mix C++ with lua. So yes, it is about balance, but it is standard procedure by now.

And with wasm (or even webGPU) one can do now the same with javascript and the web. Some logic in scripting is fine, but the heavy calculations should be lower level if one is aiming for performance.

    From personal experience, I don't believe this works in practice.

From personal experience, this works in practice.

It works well for web or other server-side tasks where your database is doing the "heavy lifting" computationally.

I believe you, though, when you say that you've seen failures of this paradigm.

It's pretty common to see issues where an inexperienced programmer is doing a bunch of data manipulation in 200 lines of Python/Ruby/PHP/whatever that could have been accomplished more easily, more performantly, and with more atomicity in 10 lines of SQL. I wouldn't say that means it's a busted paradigm. I don't consider bad implementations of a particular paradigm to equal refutations of that paradigm.

I do appreciate that there are probably arenas (scientific computing?) where maybe this approach doesn't work at all.

> the "winning" strategy is to have high-level scripting languages where you can ignore most of the details, which call into hyper-optimized, high performance libraries. For instance, when you're using Scipy, you call into Fortran and C almost interchangeably.

That gets you about 70% of the way there, but the remaining 30% is tricky. Unfortunately, the library-call stage doesn't easily (with generality) let you fuse operations. For example, consider the example of a finite-volume code, where the flux is some nonlinear function of the interface value, taken to be the average of left and right cells:

  flux = nonlinear_flux_op(f[:-1] + f[1:]) # Compute interface fluxes
  f[1:-1] += dt/dx*(flux[:-1] - flux[1:]) # Update cell volumes based on flux differences
  # Do something special for the boundaries

Each of the substeps here is fast. Sub-indexing these 1D arrays is trivial, and their local operations are highly vectorized. The nonlinear flux operator operates element-wise, so it's easy to compile it into a version that properly (CPU) vectorizes (and/or it might already be provided, like np.exp or *2). This code is also very readable.

However, real performance would require fusing operations. There's no need to compute a full temporary array for the interface values, but that's exactly what would happen in naive NumPy code. Likewise, there's no need to compute all of the fluxes before taking their differences.

A hand-optimized code would perform the full computation in a single scan of the array, keeping all of the data in CPU cache (blocking by a cache line or so in order to use vector registers effectively). Even if given the code naively written, an optimizing compiler would try loop fusion and get most of the way to the hand-optimized result.

Code such as this is relatively FLOPS-light compared to the amount of memory accessed, so effective use of cache can lead to an order of magnitude speed-up.

With a fair amount of work you can still achieve this result in Python, but to do so you need to use one of the optimizing Python compilation tools like numba. Unfortunately, this is not easy for the not-a-programmer domain scientist, since working with numba means understanding the intersection of Python and numba's imposed compilation rules.

Numba is quite restrictive... to someone comfortable in C++, coercing my code into a form Numba likes sometimes feels no easier than writing an extension using Eigen types and pybind11.

> "the "winning" strategy is to have high-level scripting languages where you can ignore most of the details, which call into hyper-optimized, high performance libraries. For instance, when you're using Scipy, you call into Fortran and C almost interchangeably"

That's nice as long as it works, but in my experience gets ugly when it doesn't. While we can currently witness this being a successful model, the impedance mismatch between both worlds is often a pain.

I bet on a language like Rust as the winning strategy in the long run - high level like Python but still close to the metal and all in one language, one compiler, one ecosystem.

Rust shares a lot of performance advantages around pointer aliasing with fortran. In fortran, pointers can't alias by default, and in rust, the borrow checker should be able to infer that a shared and exclusive reference don't alias, allowing the compiler to assume that it's not writing to input values of a loop, etc.

In C, pointers can alias by default. The last time I checked, that made these sorts of optimizations harder. However, I'm not sure how measurable the performance impact is these days.

Fortran pointers must be assumed to alias. It's Fortran's dummy arguments that must not alias.

That kind of sounds like Mojo.

> the "winning" strategy is to have high-level scripting languages where you can ignore most of the details, which call into hyper-optimized, high performance libraries. For instance, when you're using Scipy, you call into Fortran and C almost interchangeably.

Well, no. This is python's strategy. Doesn't make it the winning strategy. Python implicitly forces multiple languages upon you. A scripting one, and a performance one. Meanwhile languages such as Julia, Rust, etc. allow you to do the work in a single (fast/compiled) language. Much lower cognitive load, especially if you have multiple cores/machines to run on.

Another point I've been making for 30+ years in HPC, is that data motion is hard. Not simply between machines, but between process spaces. Take large slightly complex data structures in a fast compiled language, and move them back and forth to a scripting front end. This is hard as each language has their own specific memory layout for the structures, and impedance matching between them means you have to make trade-offs. These trade-offs often result in surprising issues as you scale up data structure size. Which is one of the reasons that only the simplest of structures (vectors/arrays) are implemented in a cross language scenario.

Moreover, these cross language boundaries implicitly prevent deeper optimization. Which leads to development of rather different scenarios for code development, including orthogonal not-quite-python based things (Triton, numba, etc.).

Fortran is a great language, and as one of the comments pointed out, its really not that hard to learn/use. The rumors of its demise are greatly exaggerated. And I note with some amusement, that they've been going on since I've been in graduate school some 30-35 years ago. Yet people keep using it.

About:

> 1. It is very likely that we will be unable to staff Fortran projects with top-rate computer scientists and computer engineers.

They are mentioning "top-rate", I'm assuming salary is not an issue. I can understand for a scientist who's job is not programming (and programming is just a necessary activity). But for a "top-rate" computer engineer, given a good enough salary and an interesting field, how hard can it be to learn enough Fortran for this?

Or am I misunderstanding what is a computer engineer?

Even for a top-rate scientist actually. Surely the programming language is not the hardest part of the job?

(not saying they should not try to move away from Fortran, there are better solutions for this field now, I mostly agree with this list full of insight)

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 every day, 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 imperative 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.

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.

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...

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.

I think it's the oldest joke in cs: "I don't know what we will be programming in the year 3000, but I know it will be called FORTRAN"

My own renaissance came via Jetson Nano where CUDA FORTRAN has some nice examples for image processing via convolution kernals. It's blazingly fast: both design time and run time!

This short film from 1982 shows the love scientists feel for "the infantile disorder":

The Beginnings of FORTRAN (Complete)

https://www.youtube.com/watch?v=KohboWwrsXg

> My own renaissance came via Jetson Nano where CUDA FORTRAN has some nice examples for image processing via convolution kernals. It's blazingly fast: both design time and run time!

CUDA Fortran was amazing. It had a really nice syntax, which did not feel that odd next to standard Fortran, and great performance. But it faced an uphill battle, was not really well managed and suffered from being coupled with the PGI compiler. I wish they’d put it in gfortran instead.

CUDA Fortran is actually alive and well, and is being carried forward into LLVM Fortran.

When a job I'm interested in uses a language I haven't used before I say that I've learned a couple already and I'll quickly learn the next one. I'd generally say each additional language has been easier than the last. I've landed contracts to code in languages I didn't know and got positive feedback about my performance.

Is there anything unique about Fortran that prevents experienced engineers from quickly learning it on the job?

The language itself? In broad strokes, not really. The typical tooling? Definitely yes, it's usually very HPC centric (MPI, OpenMP, batch job schedulers, ...).

I assume all this specialized tooling will be a hurdle in the learning process. It's not like you can spin up a docker image and hack on.

Perhaps in the future, learning how to run native binaries on bare metal, will be viewed as learning specialized tooling.

I haven't used it, but shifter looks like an MLI on docker toolset.

https://docs.nersc.gov/development/shifter/examples/

People are reasonably expected to learn k8s or React on the job, and those have a learning curve as well. Are MPI/OpenMPI much more difficult than those? I suppose that's a hard comparison to make. At first glance it doesn't look too crazy to me.

https://www.eecis.udel.edu/~youse/openmpi/#/7

MPI is trivial to learn. CS students here are expected to use it for typical scientific tasks within a few hours of lessons. Complex use cases take some time to understand backgrounds (e.g. multi partition configurations, profiling, infiniband, ...) and it's possible to become a specialist, but that's very rarely needed.

But MPI, in most use cases, comprises far less than React does, so it's not a fair comparison.

> Is there anything unique about Fortran that prevents experienced engineers from quickly learning it on the job?

No. I think that Fortran is a convenient scapegoat for LANL, not an actual obstacle. I discuss what I think the real problem is in this comment: https://news.ycombinator.com/item?id=37292569

> Is there anything unique about Fortran that prevents experienced engineers from quickly learning it on the job?

Perceived prestige, or rather the lack thereof. People with CS background often feel that learning Fortran is beneath them.

> ...prevents experienced engineers from quickly learning it on the job

The problem is in the longevity of Fortran. The variety of codes accumulated through time makes up for more than one Fortran. Modern Fortran may appear as a new language, yet still very compatible with 'classic' Fortran. MPI adds another dimension to learning it, though there's tooling around it.

The aspect of tolerance to single letter variables and cryptic function names could also be a factor, no kidding.

In general, asking for prior experience with Fortran is reasonable, just as hiring someone to "quickly learn" C on the job is quite non-pragmatic.

On LANL's points numbers 1 to 3, here's a perspective from the other side:

I think their main problem hiring is that they are looking for perfect candidates. (The same may be true for some of the other DOE labs like LLNL as well.) I've interviewed for at least 3 positions at LANL. I have a security clearance and would love to work for them, but I have never received an offer from them since finishing my PhD. (I did a summer internship with them a long time ago.) Issues like there being relatively few Fortran programmers are convenient scapegoats. They seem to want someone who not only knows Fortran, but also can easily get a security clearance or already has one, can write highly optimized MPI code, is familiar with the unusual numerical methods LANL uses, etc. They seem unwilling to hire people who are 80% of the way there. I've never programmed with MPI, for example, but understand the basics of parallel programming and have programmed shared memory codes. The most recent LANL group I interviewed with also didn't like that I quit a previous postdoc due to disagreements about the direction of the project.

In contrast, in my current job at a DoD contractor, they didn't seem to care much about what I did before or knew previously. They apparently hired me because I had some familiarity with their problem and could learn what I didn't know. I've done well in this job working on things mostly new to me. I'd like to leave because of the bad job security and bad benefits, but otherwise, I have no major problems. (And yes, I do use Fortran on a daily basis here, including some horrendous legacy Fortran.)

Given this, I don't think LANL's hiring problems will stop if they switch all their active softwares to C++ or some other language, because that's only part of the problem.

Edit: Another problem is that LANL's hiring process is convoluted. I almost got an offer from them two years ago, as the group I interviewed with liked me. But they required me to write an internal proposal which would have to be approved by someone outside of the group. I think this is part of LANL's standard post-doc hiring process, though at the time I thought it indicated that they didn't have the money to hire me and were trying to get it. There was no guarantee that the proposal would be approved. I didn't have the time then and backed out, though in retrospect I wish I went through with it as I've heard this is more routine than I thought it was.

Edit 2: Also, for clarity, not every position I applied to required Fortran knowledge. But I think my basic message is correct, in that LANL tends to be fixated on hiring "perfect candidates" when there are plenty of capable people that they could hire instead who just need to learn some things, or might not have a perfect job record (gaps in employment, etc.).

> I think their main problem hiring is that they are looking for perfect candidates.

I’ve noticed this with government and government adjacent stuff: they are choosing beggars.

The salaries they offer tend to cap well below what you can make in the private field, often are in weird areas and don’t offer relocation, and just seem terribly bureaucratic when it comes to advancement.

And yet, it seems they won’t hire you if you don’t hit their checklist to a T. I applied for a NOAA job, that wasn’t too crazy, and for the most part, was a pretty good fit for my resume. However, the application had a checkbox question along the lines of “have you ever written software for [hyper specific domain]”. I answered no and was unsurprisingly rejected. By the way, this wasn’t some wild scientific computing project, it was basically a job writing CRUD software for something that sounded interesting to me.

I really wonder how some roles get filled, I’ve seen some ridiculous asks.

As "way forward" report it covers only half the problem.

Identification of the risks including the likelihoods and hazards is pretty good. I like the notion of contrasting opinions included in the report.

But the big thing missing is mitigations: what can they do about training, about recruiting, and especially about "industry" investing in compilers? This report says nothing about ways to assure continued usability of Fortran-based codes in the next 10 or 15 years. It just lists risks. What can they do to improve the capability of GPU compilers, CPU compilers, training or staff development?

And, setting Fortran aside, what are the plans to assure continued capability in supporting and developing all of their codes, in whatever languages, in the next 10 or 15 years? This evaluation might well be replayed for CUDA, Python or Julia in the next 5 years.

The US budget for supercomputing must be in the $2G to $5G per year range, yet it seems the notion of planning a software strategy for supercomputing is not achievable.

What have you hired Lisp programmers for? I'm curious.

I fail to see how risk #6 was rated "very likely" given that neither #4 nor #5 scored "very likely".

"computing advances" probably means new software and algorithmic techniques, not (only) new hardware.

It's described more in the report. Their assessment #6 hinges on

- "Very likely" poor or non-existent robust GPU support,

- Unlikely robust support for specialized processors (i.e., non-general purpose CPU) like "Data Flow processors" and "processing in/near memory",

- Fortran advocacy and advancement is likely limited to DOE, which the report implies is insufficient, and

- Vendors of hardware have prioritized C++.

I guess “advances in technology” are not only new CPUs and GPUs, but also many other kinds of hardware and software

I can see this.

About 4: I think Fortran looks quite like C when it comes to the CPU architecture. Both are somewhat low level procedural languages.

As long as C works well on future CPUs, Fortran is probably fine and I don't see C disappear overnight. At least, Fortran compilers can be updated to produce reasonable code for new CPUs. Which should happen because of the shared compiler architecture (backend).

About 5: GPUs architectures seem less stable and seem to require specific development. If those specific developments require language support, that's probably not coming to Fortran if the assumption is that Fortran is going maintenance-only.

About 6: advances in computing technology are not restricted to CPUs and GPUs.

(disclaimer: I've only seen Fortran code from far away. And code targeted to GPUs too).

So the risks have more to do with adoption of the language than the language itself?

I studied Fortran in my college programming languages class (in the early 2010s) and loved it! Always wondered why it isn't used more.

>> I'm not sure what the big iron imperative language offers

Does any other language have built-in COMPLEX type? Or funny (but fast!) stack-free function calling?

Common Lisp has complex numbers: https://lispcookbook.github.io/cl-cookbook/numbers.html#comp...

Is stack-free function calling equivalent to tail call optimization? If so, then many CL implementations support it, including SBCL. For Scheme, it’s part of the standard.

Statements like these without discussing the language standard most of the Software you have uses is kind of pointless.

I guess most of the legacy code for which they do this risk assessment is Fortran 77. Not any more modern.

And getting it up to date to modern fortran would be as much effort as any other modern language.

The report mentions both "modern Fortran" (which they explicitly specify to be Fortran 2008) and "legacy Fortran" (which they don't further specify, but I assume is 77).

In the community, “legacy Fortran” is pre-Fortran 90. Modern includes everything since then, so right now up to Fortran 2018.