No, and there would never be such a discussion, because C and Fortran are languages of fundamentally different purpose. C is a low-level systems programming language, which happens to be used as an alternative to Fortran in numerical computing, which only speaks volumes how irrelevant Fortran has become, that it become triumphed by a language so unsuitable for the task.
C does not require any new features to stay relevant. Fortran, being much more abstract language and used by a different set of professionals, unfortunately does. Slow evolution of Fortran means its death.
Thankfully, there are many amazing people who do amazing job to push it forward.
Here you show a good example of the language and the libraries/environment having a good synergy to the point of being almost one!
If one uses FEniCs from the python interface it makes your life easy and gives acces to performant libraries written in C/C++. Most of PETSc is written in C. Just like Numpy.
And just like for PETSc one can have access to MUMPS from python PyMUMPS · PyPI … and hey, MUMPS is written in Fortran.
No one is stopping Fortraners to profit from the strengths of the Python environment to use it as an interface for exposing also performant librarie and simultaneously develop the Fortran ecosystem in parallel.
Some of what the author says makes Rust, more so than C, a good complement to Python, also applies to Modern Fortran.
Python is easy to write, but slow to run. It’s so slow that you can’t write high-performance libraries in pure Python, and in particular you can’t write data processing libraries that way. And yet Python is the dominant language for ML and data engineering. So, if you want to write a library for data engineers, ML engineers, etc., you’re going to find yourself in a situation where:
You need to use Python for the API, but
You can’t use Python for the “real work” of high-performance data processing.
Historically, this meant that would-be library writers had to do one of two things:
Learn to program in C, or
Hope that somebody else learned to program in C, and that they wrote a library you can lean on for the low-level stuff.
“Well,” the C-philes may be asking, “what’s so bad about that?” Maybe most library authors can get the job done by outsourcing the number crunching to numpy or scipy. And in the handful of cases where it’s really necessary, surely they can learn a little C. It builds character.
In practice, it just doesn’t work that well. Being able to outsource things to numpy, scipy and the rest is nice when it works, but having to vectorize every function and not being able to write for loops is a pain. Wondering whether something will be GIL-blocked is a pain. And on and on. Not everything you want to do fits neatly into existing libraries.
OK, so what about Option #2: Why not write the library from scratch in C, and throw on some Python bindings? The problem is that if you’re coming from a Python background, programming in C is going to seem very low-level; it takes some work to learn the language. Null pointer dereferences, buffer overflows, memory leaks… these are just a few of the many fun Ways to Shoot Yourself in the Foot with C, all of which are foreign to native Python programmers.
If only there were a better way. If only there were a language that’s as fast and memory-efficient as C, but which didn’t require manual memory management or garbage collection.
I think one difference between C and Fortran is that while both are languages that do not follow the “Batteries included” approach of Python, Java or the .NET-languages, a huge number of C libraries is included in the repositories of the major Linux distributions or similar software distributions like MinGW or Fink, where everything is smoothely installed on the system. So you have de facto a “batteries included” situation again.
A lot of great work has been done to improve the situation both concerning the availability of libraries for fortran and the development of the package manager fpm by the people here.
Still for C and C++ developers there’s a very good infrastructure of libraries that are basically included in your development system.
Disclaimer: I do not know whether this is important for people working professionally on large real-life projects, but it may be important for people starting a small software project.
Very well said. The “batteries” and infrastructure are crucial.
Fortran has many batteries (the existing Fortran libraries), but they are not quite easily available to users, especially new users — much more difficult than a simple and platform-independent import in Python. In this sense, Fortran does have batteries included by default.
def convert_int_columns(df:pd.DataFrame) -> pd.DataFrame:
"""Convert float columns to integer if all values are exactly integers."""
for col in df.columns:
if df[col].dtype == 'float64' and (df[col] % 1 == 0).all():
df[col] = df[col].astype(int)
return df
fails if the pandas dataframe df has duplicate columns, since then df[col] is not a Series (1D) but a DataFrame (2D). Finding this bug cost me an hour this morning. In Fortran the type of an expression can be inferred from the types of the variables in the expression, which eliminates one class of bug. In fairness to Python, the ability of a Pandas dataframe to hold columns of different types is quite useful and is not possible in a Fortran 2D array.
There is really not much in the python stdlib (the batteries included part). I’d bet no one uses just a plain python installation. Remember, matplotlib, numpy, scipy ,etc are not ‘included’. Nor are all the ML libraries much of python is used for.
What python and other ‘modern’ languages have going for them is the second mover advantage and faster hardware. They get to build on the successes of fortran and c/c++, use an interpreted interface and modern distribution technologies.
IMHO, the fortran community should be targeting all the basic fortran libraries that constitute the backend of python, modernize them and include them in stdlib, then tie the python libraries to stdlib.
In this way, we tie together the development of Fortran and Python
I’m a scientist who uses Fortran (since 2008) and Python (since ~2011 for scripting and teaching) in a complementary fashion, because I view them as a nice “team”.
There are several causes I see:
I wouldn’t say using Python properly is easier, but it’s easier for prototyping and to get quick results (because of the larger community, online resources, no use of Makefiles and “manual” compilation, etc.). Unfortunately, academia is changing to reward quantity of output more than quality. Couple this with job insecurity and a system that creates lots of pressure and an ever increasing sense of “if I don’t deliver more output per year, there’s no chance of finally getting a permanent position in my 40s”. This plays into the hands of Python due to said advantages. Even with the awareness of the limitations of Python and advantages of Fortran, C++, etc., they are more likely to opt for Python.
They are more likely to pick up Python than Fortran codes of others, because (a) they are already more familiar with Python than with Fortran, (b) job insecurity makes them think about what will be more beneficial if they’re forced out of academia (and they see more job ads requiring Python skills), (c) and the system doesn’t reward learning anything new unless it results in more output (so you carefully weigh how to spend your spare time). All that contributes further to the spread of Python in science.
If I propose teaching students Fortran, teaching directors will have my head, because (a) it will scare away students and thus have a notable negative financial impact, (b) Python will increase the employability of students more than Fortran and most students will end up in Python dominated industries. All this happens even in context of a “computational geoscience” study programme and a scientific discipline, where Fortran is the dominant modelling language. This results in young academics knowing Python and generally being keen to dethrone Fortran there/replace everything with Python for convenience (and due to the pressures described above).
I see why many people prefer Python over Fortran: for the same reasons many prefer a scripted language over a compiled language. Easy to write code, get results faster, etc.
The real qusstion is why Python specifically and not, for example Julia or Matlab, which are faster (especially Julia)
I think that (partially) the preference of Python over Julia/Matlab is that, since it is not a domain-specific language, it’s easier for it to attract software engineers besides only scientists. This also comes with all the better tooling available thanks to it being a popular language in the software industry
Good point. In any case I think that Python (or Julia/Matlab) and Fortran are more complements than substitutes. When working on a research project, I use Matlab for plotting, analyzing results, etc. while I do in Fortran the heavy computations.
An advantage of Julia over Matlab is that it is easier to call a subroutine written in Fortran from Julia rather than Matlab. For some weird reasons, Matlab officially supports only Fortran 77, see here: Create Fortran Source MEX File - MATLAB & Simulink
I use the Python community to promote Fortran code wrapped in Python packages 