People often wonder why someone would use Fortran over Python for scientific stuff.
Fortran is often considered inept by proponents of “newer” languages (which are often scripting languages) because it first appeared in 1957, and is considered old. They think life with Python is easier because of the myriad of libraries, I mean with NumPy and SciPy you can do lots of number-crunching. Sure that’s true, but not all that glitters is gold. First of all Fortran is fast, nearly as fast as C in some cases, and sometimes even faster (things where Fortran has syntactical features that increase efficiency, e.g. arrays). Python is just not fast, not in any realistic sense of the term.
Secondly, Fortran has a lot of number-crunching libraries, some of which may be old, but here’s the thing with Fortran, it is backwards compatible. So it’s often easy to get a library written in 1981 to work. Now some modern languages are open source, e.g. Julia, and while that seems nice, it makes it hard to maintain a sense of stability, and backwards compatibility goes out the window. It’s one of the main reasons I stopped using Julia★. Languages like Fortran (and C), are more stable because language changes are made sparingly (there is a reason standardization exists, and why it takes 3-5 years to make changes – stability is a good thing). So anyone that writes software in Fortran can have confidence in any Fortran libraries they are using and in the longevity of their own code. This helps protect against code rot where code becomes usable due to dependency failures, or even changes in the implementation of the language.
It’s also hard to really compare Python against Fortran for number crunching ability. Python is a scripting language (and there isn’t anything wrong with that), and in reality isn’t that powerful. In addition, you can create stand-alone programs in Fortran – not something that any scripting language can do well or at all. Ironically some of the libraries used by Python are just wrappers around existing libraries written in, you guessed it, Fortran. A good example is MINPACK, used for solving systems of non-linear equations – NumbaMinpack is a Python wrapper to the MINPACK library written in Fortran 77. OR the some portion of the code in a Python library is written in another language (I would imagine the things that would run sub-optimally in Python). Why not rewrite these libraries in Python? Perhaps they wouldn’t be as efficient, or perhaps it’s just software reuse at play. So sure, Python is okay for proof-of-concept work, but honestly scaling up to industrial use has to be done using an established language, be it C, C++ or Fortran. Also Fortran is easy to learn, which is certainly a feather in its cap.
If we look at the TIOBE Programming Community Index, yes Python is on top (14.82%), with C second (12.08%), and Fortran is at 16th position at 1.02%. However lots of people use Python for a lot of things, it is very popular. Would I write a large scale climate model in it? Ahhh… no. Note that MATLAB is at 14th position at 1.27%, and Julia at 28th position, at 0.58% (November 2023).
★ I really saw a lot of potential in Julia, but the changes killed it for me. I don’t want to write a library and then in 6 months rewrite the library because the language spec has changed. I can write a library in Fortran, and it won’t change.
