> And with excellent, state of the art libraries. What’s not to like?

Here's my gripe with Fortran: as a computer scientists that works with combustion chemists, astrophysicists, and nuclear physicists, it's disheartening to see the number of domain specific optimizations that these scientists hand code over and over and over ad nauseam in hundreds of code bases all around the world simply because they think their Fortran compilers are good enough. They don't realize that it would be much more productive if their communities standardized around individual DSL compilers capable of doing higher level transformations specific to their individual domains so they don't have to do complicated transformations by hand (and often mess them up). It's fine if those DSL compilers generate Fortran out the back end so they can interoperate with existing optimized Fortran libraries, but holy hell people, we are living in the 21st century, can we please stop programming in primitive data types (without any unit type checking to boot!) and calling MPI send/recv directly. Scientists have better things to be doing with their time than managing bits directly; raise the level of abstraction by building community specific DSLs, standardize, and let's get on with our lives.

Meanwhile, you can take the code from a paper of 20 years ago and it will run flawlessly, without going through dependency hell and battling compiler versions. Code reuse is not always a good thing; self-contained, zero-dependency code is often extremely important. I’ll stay with Fortran for my physics needs, thank you.

Fully agree, although it's not really a gripe about Fortran, is it? I suspect it would be the same with another language, given the same users.

It's true that it could happen with any language, but it seems to be especially prevalent and widespread with Fortran. Something about the culture of the language encourages people to dig their heels in and assert that it is good enough.

I have to use Fortan as part of my day job and mostly don't like it. What I hate most of all are the lack of any decent string data type and built in C++-STL-like data structures library. It would be great to have hash maps, etc. The poor built in library compared to Python and Scipy is extremely frustrating. It's very hard to get anything done which is not just array manipulation.

The Fortran I worked with in my minicomputer days was for the most part 100% standard, the exception was its string handling.. which was excellent. So I wrote all kinds of text translating tools (and lots of other tools) using that Fortran compiler. That was a long time ago..

i agree with you. it really reads like Python and seems more explicit from the little i have seen. i wonder how you went about learning it? can you recommend a book? thx.

Yep. That's the community I had in mind. Particle physicists love Fortran :-)

However, I'm not so sure about the speed argument anymore. And in any case for most applications (which are rarely big simulations) it's not worth the sacrifice of readability and modern tools IMO.

Even at CERN people are re-writing some tools in python. (probably wrapping some C++ code, but still ... it's not Fortran).

A youtuber that I follow recently finished his PhD and used FORTRAN extensively. He said that he started with python and it was incredibly slow so he rewrote everything in FORTRAN.

It may be that his use case (something with cloud or other weather modeling function) was just particularly well suited

Any compiled language will be drastically faster than an interpretive scripting language like Python (although numpy/scipy is generally C or Fortran libraries compiled to be called by Python). Having said that I used Fortran for my PhD to do radiation simulations because I was implementing a new methodology into existing code.

In my opinion Fortran is easier and safer to use for scientists with little background in coding because it was built to do math/simulations really well AND it's readable almost like psuedocode (compared with C or C++). Also, modern Fortran is object-oriented which makes building reusable tools and large packages pretty easy.

Having said all of this I think a lot of the physics/nuclear/aerospace/finance community is probably transitioning into more modern languages and starting to employ people with actual CS backgrounds to build with more updated coding practices.

Did they write python correctly though? If you vectorize your algos well enough to exclusively use numpy scipy and never use python loops then python is really really fast (not because python is fast but because numpy/scipy is fast)

Numpy/Scipy are fast, because their backend is written in Fortran :)

I think if we push this to the limit we would all be writing assembler or making circuits :)

Exactly. That's why I say that the speed argument is a bit obsolete by now. We can have the best of the two worlds with python! Elegance/simplicity and speed.

The focus on the speed of execution also downplays two other important aspects of python: speed of writing code and possibility to visualize results easily. As a theorist these two aspects outweigh any argument in favor of Fortran. The only serious competition to python for me is mathematica.

The truth is, any language other than Fortran/C is slow for any serious high-performance-computing task (which is not the same as everyday back-of-envelop calculations and plotting).

these days if you want fortran fast python you google julialang

I do use Julia; however, it is too immature to serve as a viable Fortran replacement. Still, a great language.

CERN is an exception; they are famously a C++ shop. I really really don’t like C++; nearly anything else is preferable to me. Fortran is simple and math-oriented; C++ is horribly complicated and system programming oriented.

There is a subset of C++ that is really pleasant to work with, performant, and simple-ish. Unfortunately, the community around the standards/development processes just seem to want to keep adding more, more, and more to an already top-heavy language. Every idea in language design just must be added in.

When you add in the problems from legacy C compatibility, you have a language that no one person can ever hope to grasp in its entirety. I mean, it's so complex now it pushed Scott Meyers into semi-retirement.

I wish they would have just dumped C legacy stuff and started over some time in the 90s. Actually, the language D is precisely what I wish C++ had become. I just wish D was more widely adopted.

when I looked a few years ago they where recruiting for Fortran