By no means am I suggesting that it wouldn't have an advantage; I'm just a young whippersnapper who has never had the chance to write any Fortran.
Thinking about it, I'd say the comparison to Rust for mastery of its particular domain is actually quite apt.
I cut my teeth on Matlab, and flipped a coin for Python or Fortran as my language to focus on after Matlab tried to charge our HPC center per core.
Python won the toss, but I've always had a love for Fortran.
There's a lot to learn in higher level physics, so having the simplest language, without tons of features to fiddle with, while also being very, very performant is preferable.
I have a feeling that much of this work end end up in Julia however.
They use % as the accessor instead of . (Yes I am joking around) ;)
FWIW...Fortran has had explicit OOP features since at least the 2003 standard (e.g. "type extends"). You aren't "required" to learn those features to use Fortran, but that's true of any number of ostensibly OOP languages.
Lastly...endless people (virtually always non-physicists who wrote a couple of lines of Fortran-77 in college) are continuously popping into the conversation with "well of course dump musty old Fortran for the NewHotness language because ew Fortran". Hasn't happened yet, and the Fortran folks have evolved from -77 to -90, -95, -2003, -2008 and lately -2018, so why would it?
I’m wondering why Fortran is dominant in physics yet APL in finance.
I remember writing some data analysis code in Fortran for my freshman physics lab and the TA was surprised to see my choice of language.
Pretty much everything you would ever want to do related to partial differential equations or computational fluid dynamics has already been written in FORTRAN, and is damn good code.
It helps the the language itself is more than capable of great perforamance and that NASA has poured massive amounts of cash into making sure it stays performant on newer hardware.
Rust is also pervasively noalias, but it's taken years for it to actually enable "noalias" on LLVM. Rust code uses that feature more than it's ever been used before, which keeps exposing codegen bugs that no one noticed before. Once those get flushed out, I still expect it will take a while for the resulting optimizations to reach the quality & maturity that Fortran has had.
From the noalias = no panacea
To the Fortran repl
Thank you. This was inspiring.
Maybe it’s time I learn me some llvm too. Cheers.
C has some similar legacy but came a little later to the game and wasn't as intuitive to people driving the money in computing as they were with FORTRAN. It's also heavily optimizeable from a performance perspective but often missed the initial buy in and momentum, though developed much of its own.
So FORTRAN has a lot of investment and strategic advantages to be used for things like weather modeling, at least for specific underlying libraries. Modern work tends not to start from greenfield in FORTRAN, it often starts in C or really a high language like Python to provide theoretical proof of concept and just write/use wrappers to highly optimized codebases like those for FORTRAN for the numeric fundamentals in the model. Lots of scientific glue code these days with not a lot of stuff making it into optimization levels like you see in BLAS, LAPACK, ScaLAPACK, etc.
Python and matlab being to slow at “low barrier to entry level” for sure anyway.
I’m not going to comment on julia because I’m still drinking coffee. In theory… blah blah maybe it should fill this role.
Sit down, write stupid simple Fortran code to solve a large linear algebra problem (a discretized partial differential equation system) and things like matrix multiplication and numpy style mat(:) access are built in. (Numpy borrowed the syntax from fortran, actually)
For a scientist, this is way easier than wading into c++ and getting it right; or sticking with c, and avoiding the footguns.
Fortran gives you maximum serial speed with minimum effort… it is easy to write efficient serial code, while knowing almost nothing of programming. Memory management sure, but even there, there out of the box are no pointers to fumble and your allocations are going to be contiguous. Optimal Array Memory access comes down to knowing Fortran is column based.
Ah but then you need to go parallel, where the documentation more in c these days.
But you’re already comfy with Fortran now, so, scientist that you are, you dig and experiment until you get it running in openmp, mpi, and cuda, etc.
(Yes I know it’s simulink for many, but I’ve met some pure computational folk who swear by matlab as their prototyping tool and python is a bug ridden rat nest of footguns to them.)
C’est la vie
These days, scientific computing is a relatively minor niche, because people have found so many other things to do with computers that science is just one of many use cases.
Fortran was aimed at a specific audience, scientists and engineers, and that audience seems - AFAICT - happy to keep using it. One may consider it an impressive success story.
Personally, I have never used Fortran for anything beyond the hello-world-level, so I have no strong opinion on the language as such; I do know it has evolved a lot, probably more so than C.
The only reason Fortran is still around is institutional inertia.
Personally, back in the days, I never really got into the NAG libraries. I found it easy enough to roll my own. Maybe some of the stuff can save you time, but I ended up preferring hand-coding my algorithms.
The greatest thing to happen to Fortran was Fortran 90. None of that column malarky. Modules was kinda OK, but if I wanted to use well-structured code I probably wouldn't be starting with Fortran anyway. I don't think ANYONE I knew at the time used to new features other than format-free.
I tried poking around with allocatable arrays at one point, but didn't like it. I guess it was Fortran's way of trying to be like C.
One thing that is rarely discussed is that a programming language isn't just specification, but it is a culture and philosophy shaped by the programmers themselves. One guy made a reference to Cobol, and how object-orientation was an unused feature. He said that what the designers failed to consider is that Cobol programmers just don't "do" object-orientation.
Fortran - even Fortran 77 (IIRC) has some nice little features, like being able to specify parameters in a separate file, and read them in one line. I doubt most of the other guys in the faculty were aware of that feature at the time.
And my standard anecdote ... when I went to a new job, they actually had a little bit of programming in Fortran. We had Visual Fortran. I had to set up the environment to fiddle with something for a client. Set-up was straight-forward. I opened the project file, and the things opened and compiled without a single hitch. I was shocked - shocked I tell you - at how simple the set-up was. Normally one would expect endless futzing around to get the programming environment and libraries in place.
But that's not the real anecdote. One day I was passing by a meeting room. I overheard an outside consultant in discussion with some of our guys about a replacement for Fortran. He was going on about how flexible the system would be, and hey, it you needed to set up extra parameters you could always add them to an XML configuration file he was proposing.
And I thought to myself ... my God, that's complicated. In Fortran, you can read an array into a file in one statement. Bam! His method would have involved external libraries and some serious effort to get going.
I always joke that people should be forced to write Fortran for at least a year. For those that want to be JavaScript developers, two years. That should make people think much more simply about what it is you're trying to do.
A year ago I added programming microcontrollers to my list of things programmers should be forced to do. A resource-constrained environment should focus their minds a little more.
This is what Fortran's namelists are for.
Another point: This thinking cheapens learning. If you only learn, "what isn't dead", you stifle your curiosity and don't learn the whole picture of a thing.