Fortran is the favorite whipping boy of the programming world.  People feel completely comfortable making condescending statements about the language and those who use it.  I've been coding since I was 12, taught myself three languages by 10th grade (including 6502 machine language coded in hex), and learned several more by the time I finished grad school.  Fortran has become my language of choice for many reasons, but being "stuck" isn't one of them.  Expressiveness is part of it.  Support for mathematical calculations is another. And performance is very high on the list.  But the number one reason from which most of my other reasons flow is that Fortran is the only language with an international standards body that sees scientific programmers as its target audience

On performance, take a look at this comparison of Fortran, C++, and Python in a domain of broad interest in physics (solving PDEs):

http://www.hindawi.com/journals/sp/2014/870146/abs/

Python isn't even in the running and C++ only comes close on the largest problems.  And on the performance question, I think it's important to note that, in the multi-core/many-core world, high performance necessitates parallelism.  Fortran is the only  standardized language with its own high-performing and scalable parallel programming model in the form of Fortran 2008 coarray parallel programming.  If you download OpenCoarrays (www.opencoarrys.org), the test suite contains multiple PDE solvers, including

(1) an object-oriented, parallel Burgers equation solver that has been shown to scale 16,384 cores with 87% parallel efficiency using nothing but Fortran 2008 with no need to embed any compiler directives or calls to libraries external to the language (I'll be glad to provide references if desired), and 

(2) a spectral Navier-Stokes solver for which the coarray Fortran version outperforms the MPI version even when the compiler uses MPI under the hood to support coarray communication and synchronization.

While I think Python is wonderful and is great for scripting purposes, I'm more likely to move to something like Julia if and when I finally switch away from Fortran for production code.  Like Fortran, Julia was conceived with numerical computation and high performance in mind.   For a great perspective on languages for scientific computing, including Fortran, Python, and Julia, see http://arstechnica.com/science/2014/05/scientific-computings-future-can-any-coding-language-top-a-1950s-behemoth/. 

Many things can cause a group to stick with a given computer language.

Reuse of existing packages is one.

Ability to know and understand how boundary conditions (underflow and overflow) are handled is another.

Access to support environment for debugging and testing performance can be another.

Support for input and output of large data sets can be a factor.

Ability to express well understand algorithms is important.

Support for parallel processing can be a factor.

There are many reasons languages such as FORTRAN, COBOL, and SAS have their loyal following despite the creation of languages that can be in principle be considered superior. 

Thank you John, you are making good points.

Let me try to discuss your points, one answer at a time..

1. REUSE:

SciPy and NumPy are already supposed to be built upon the long standing history of the Fortran legacy, rewritten and tested in the new language Python (and its high performance derivatives).

Also reusability among Python projects is very well demonstrated by the extensive ecosystem that is now in place around Python.

A physics paper publishing results out of a Python-ported numerical computation today, will have no problem in the (long term) future to be reused, cited and verified by independent research groups worldwide.

2. BOUNDARY CONDITIONS.

If I well understood your point here, what is necessary to be able to do here that cannot be done with a Python based framework? It looks to me more related to how you formulate a problem, than which language you are using to express boundary condition, right?

3. DEBUGGING AND TESTING. In my experience, the time spent on debugging and testing a Python program is less than 50% of any other language framework, including C, C++, Java. No experience un debugging/testing with Fortran, but I can imagine...

4. BIG DATA INPUT/OUTPUT. Python has a native support to memory mapped I/O wich is the most efficient way to read large files that I know, regardless of the language you use.

https://docs.python.org/2/library/mmap.html

5. READABILITY OF CODE. Python is definitively the best! And this is the key to its success. Have a look at the included SciPy.Org documentation page about integration methods.

Also , a Python program can be transformed almost in a paper-like form using the IPython Notebook, where code, formulas and graphs are easily blended together , like you can see from the second link.

http://docs.scipy.org/doc/scipy-0.14.0/reference/tutorial/integrate.html

http://nbviewer.ipython.org/github/jrjohansson/scientific-python-lectures/blob/master/Lecture-3-Scipy.ipynb

6. PARALLEL PROCESSING. Well, on a Unix/Linux machines many of the message passing, shared memory software architectures well known in literature are already supported by a Python environment. Also a native multiprocessing support is documented in the link.

https://docs.python.org/2/library/multiprocessing.html

John, on the more general issues you were mentioning as your concluding remarks, I can say that keeping all of the legacy Fortran code as it is, new team members should be encouraged to explore how to integrate new Python code into it, starting right from the I/O subsystem. 

Perhaps one more argument.  I, for example, feel very uncomfortable, like an ape with razor - not knowing what am I really doing using new efficient languages.  Unconditional trust?  No way, too many bad surprises in past.

I've heard a lot of time its legacy code that works and no one wants to touch and migrate.  Old habits

Marek, you can actually use the line debugger with a Python program going as deep as you desire into source libraries code, which are not perfect , we do agree. You can even show the assembly language generated out of a user defined function. There will be a point when you will only have to trust the under hood CPU system.

I hope the link can help to remember the history about the boundary of trust.

https://en.wikipedia.org/wiki/Pentium_FDIV_bug

1. What keeps physicists stuck with Fortran?

It's sort of like asking why someone speaks only english or prefers beef over pork--often these conversations turn religious.

Pragmatically, in a team environment, one prefers to speak a common language with colleagues to communicate ideas effectively, and read/write and easily comprehend codes. Maybe it's the Inertia of a large mass--tends to keep going without change in direction and without much friction.

2. Performance?

Yes. Also, coding practices (lack of wide pointer usage) and existing optimized modules (purpose built in house libraries) tends to keep these codes performant.

3. Portability?

Definitely.

4. Scientific evidence?

Not sure what you meant by this...

In summary, it's a matter of taste and habits of a group, and besides the language keeps evolving in a decent manner and with the notion "if it ain't broke, don't fix it."

Giovanni,

This is misunderstanding.  "The ape with razor" is by no means related to the very detail of generated assembly code, it's on different level. I don't care what code is behind a simple formatted PRINT statement in Fortran (and it is surely much longer than a simple assembly language statement).  But I'm very unhappy to have at my disposal a system-delivered (built-in) fancy function performing, say, some kind of optimization by minimizing a "vector norm".  Without ever mentioning which norm.  Here is where I don't know what I'm really doing, no matter that the results may seem sensible and are produced suspiciously quickly.  Besides, digging into 500 page book (the one I have on Python) is tiring, especially for a newcomer.

I agree with this suggestion to adopt the new language but it depends on the requirements of a particular project. In my opinion, this question will be more interesting if Giovanni De Gasperis  could provide some numerical result for the execution time for same codes using the Fortran and Python.

As many colleagues said above, I believe thta it's just a matter of purpose. The computer languages are tools, in fact interfaces, to perform calculations. If your main propouse is speed no matter what, FORTAN (or C, etc) may be the answer. But if reprodutibility, development speed and utilization of additional libraries, I would recommend a script language such as Python, Perl or Julia. But among those three I would definetely recommend Python.

Important to say, as many colleagues have spoken as well, the main tools that allow Python to be fast (like the numpy arrays) has its kernels implemented in FORTRAN and/or C, so Python works just as a interface.

One can make an argument that compiling a program provides a level of protection not provided in a scripting languages. The compiling of a program insures the entire program can be parsed and transformed into an executable.

Fortran is the favorite whipping boy of the programming world.  People feel completely comfortable making condescending statements about the language and those who use it.  I've been coding since I was 12, taught myself three languages by 10th grade (including 6502 machine language coded in hex), and learned several more by the time I finished grad school.  Fortran has become my language of choice for many reasons, but being "stuck" isn't one of them.  Expressiveness is part of it.  Support for mathematical calculations is another. And performance is very high on the list.  But the number one reason from which most of my other reasons flow is that Fortran is the only language with an international standards body that sees scientific programmers as its target audience

On performance, take a look at this comparison of Fortran, C++, and Python in a domain of broad interest in physics (solving PDEs):

http://www.hindawi.com/journals/sp/2014/870146/abs/

Python isn't even in the running and C++ only comes close on the largest problems.  And on the performance question, I think it's important to note that, in the multi-core/many-core world, high performance necessitates parallelism.  Fortran is the only  standardized language with its own high-performing and scalable parallel programming model in the form of Fortran 2008 coarray parallel programming.  If you download OpenCoarrays (www.opencoarrys.org), the test suite contains multiple PDE solvers, including

(1) an object-oriented, parallel Burgers equation solver that has been shown to scale 16,384 cores with 87% parallel efficiency using nothing but Fortran 2008 with no need to embed any compiler directives or calls to libraries external to the language (I'll be glad to provide references if desired), and 

(2) a spectral Navier-Stokes solver for which the coarray Fortran version outperforms the MPI version even when the compiler uses MPI under the hood to support coarray communication and synchronization.

While I think Python is wonderful and is great for scripting purposes, I'm more likely to move to something like Julia if and when I finally switch away from Fortran for production code.  Like Fortran, Julia was conceived with numerical computation and high performance in mind.   For a great perspective on languages for scientific computing, including Fortran, Python, and Julia, see http://arstechnica.com/science/2014/05/scientific-computings-future-can-any-coding-language-top-a-1950s-behemoth/. 

Damian - thanks for mentioning our paper. I do agree that Fortran is faster than Python, but one of the point of the paper (http://www.hindawi.com/journals/sp/2014/870146/abs/) was to show that Python can be faster (especially with some extra tools/library/interpreters - e.g. PyPy) than most people think.

I also believe, that not all scientists (and definitely not all the time) have to think only about the running time. Coding/testing/learning time is also very important.

Marek Wojciech Gutowsk: People write papers about fancy functions/scientific schemes (because this is something that you might need to use in your work) and many of them are implemented in Fortan. Using them with full confidence from Fortan might be as hard (harder ?) than using from Python. 

40 years of linear Algebra libraries.

mpi implementation in f77.

Massive parallel computing in f77.

Need I say more?

Python is for pussies (i.e.  psychologists and economists).

I may deviate from the gentlemen who prefer it in FORTRAN. I did switch to C/C++/C# almost 15 years ago. I do feel I did the right thing. There are so many libraries in all branches (math, GUI, etc.). Honestly, to be a C programmer, it means that FORTRAN is a peace of cake. But not the other way!. C enables you to write low-level codes and, hence, giving you larger flexibility over your code. You may also import other languages into your C code pretty easily. There is a wide range of bonuses you get with C programming. Try it and see for your self. Regards.

Ansi C interoperable with f77.

please u have speed classification of languages ... look at google ... python is very very very slow.

... and we are not stuck with fortran, we love fortran! It is the languange of numerical science, math, geo science, of course c++ has some benefits but it is not very handy for scientists. Everything else cannot be used because of computational speed ...

Everybody's preferences are strongly related to practical needs and available libraries to satisfy them. Python is a great tool for measurement data collection and manipulation, but it will need to develop a lot of models to compete with Matlab/Simulink optimization or system recognition toolbox libraries, for example. There are many counter-arguments, but, again, everything depends on particular needs, where speed, convenience and other arguments become widely negotiable.

I think one reason is that several generations of physicists have used fortran language in their programs and created a lot of subroutines and libraries. These programs constitute today a reached "gallery" of solved numerically problems   that is very useful for future generations. Another reason is that the old physicists have difficulty to shift to an different programing language like as Python or C, C++, etc.

Bejo, be assured that for a good physicist, young or old, moving to a new programming language is not a big deal.

Hehe, this is actually a very funny statement:

"Nowadays all of the major Fortran related numerical calculus have exactly mapped equivalent libraries in more modern language framework like Numerical Python (NumPy) and Scientific Python (SciPy).

What keeps physicists stuck with Fortran?"

Do you know why? Well it is funny for the same reason NumPy and SciPy can not be faster than Fortran by definition. This for the simple reason that the NumPy and SciPy libraries are wrappers  around C wrappers around FORTRAN code. 

So when you move to SciPy and NumPy you are actually still using Fortran...actually it is worse, you are still using FORTRAN 77 mainly, while most Fortran programmers have moved on to Fortran 95 and Fortran 2003. (If you don't believe this, try to trace a high performance NumPy routine down to the source code, you will  be surprised.eg leastsq)

Guys, thank you for your hints. I like very much the approach reported by Aldo Dall'Osso, which is were NumPy is founded. I am personally starting to use PyPy, the just in time compiler, with multiprocessing and the models fits my applications domain (text mining, extended gaussian algebra expressions and logic programming).

Looking forward to learn more about Julia, seem's very promising.

Cheers!

There is no need to convert old code into Python because you can call fortran code directly from Python using f2py.

You know it becomes harder to learn with aging , and physicians love the traditions . 

Btw, I like the approach of Software Carpentry web site on one of their Python online course for scientists:

the time to arrive to a solution is given by:  Ts = Td + Te

where

    Ts : time to the solution

    Td: time to focus on the problem, think of an algorithm, write a program, debug it

    Te: time of execution

Nowdays Td>>Te, that is why i am definitively stuck with Python/Numpy/Scipy.

Cheers!

http://software-carpentry.org/v4/python/intro.html

Why you want to "replace" fortran with numpy+scipy if scipy is in a considerable amount fortran and also numpy has fortran code? 

The issue here is not to "replace" anything. How about the NEW problems that physicists want to tackle. Why they keep pushing young students to be stuck with Fortran, while those students could learn a new and fascinating language the improve their productivity by orders of magnitude?

It really depends what the students are doing. 

If they are analyzing a small data set and looking to make some plots, obviously python will be faster to code and easier to use. 

However, for any serious simulation or numerical computation, Fortan will be many times faster. Also, if you want to parallelize your code (for clusters or GPUs) it is very difficult to do that with Python. Parallelization really can give a research group an edge and is becoming more and more popular. 

I'd also argue that for many things Fortran is easier to learn than C and even Python. The programming model that Fortran uses is much easier to learn than the Object oriented model that Python is built around. If you wish to go object oriented, you can use Fortran 2003, but you don't have to learn it from the outset. 

Fortran offers a nice mix of ease of use for numerical calculation and raw speed which is so far unmatched.

The fact that physicists still use Fortran is more of an indictment of the computer science community than of physicists. The fact is, they have not yet developed a better alternative that combines speed and ease of use. The closest thing is the Julia language which is currently being developed. 

I have written about this in much more detail on my blog (see attached link). 

https://moreisdifferent.wordpress.com/2015/07/16/why-physicsts-still-use-fortran/

Dear all,

I am glad to see a great open science initiative from the LIGO research team that published a web page about the gravitational wave event with the full dataset and a scientific Python program so anyone can re-analyze it. 

(see attached link)

https://losc.ligo.org/s/events/GW150914/GW150914_tutorial.html

Python is slow?

https://youtu.be/EEUXKG97YRw?t=195

I am using Fortran actively only about half a year, in the course of my PhD project – a requirement, because I'm writing an extension to an existing code. However, while the original reason to pick up Fortran was related to the age of the code, I found that it really makes life easier for implementing mathematics. 

The equations I have to implement – preferably as close as possible to their written form to keep them readable – are most easily written in an index notation, which would be extremely inefficient when using e.g. Python or Matlab; Rewriting them to use efficient array operations provided by these languages would obscure their interpretation, especially when it involves 3rd or higher rank tensors. (Note: numpy.einsum may partly solve these issues, and indexing without temporary variables in fortran may result in lost performance due to non-continguous memory access). 

C, C++ would allow efficient index-wise operations. But neither has builtin support for dynamically sized multidimensional arrays; In C++ at least libraries can provide more convient syntax here, but this still increases the learning curve compared to Fortran. (Disclaimer: So far I didn't use C/C++ for anything beyond "trying the language" and some exercises in computer science lectures.)

Granted though, Fortran has its own shortcomings – notably the limited support for generic programming and, possibly related, the lack of anything like C++'s STL (e.g. a generic, type-safe linked list). 

If you use some standart numerical methods, Python may be fine. Indeed, modules like scipy are actualy compiled C or FORTRAN code. But if you are going to develope something original, procedures that are not exist in standart Python libraries, then FORTRAN is significantly better. It will work many times faster then Python.

I realize that's an old topic, but just wanted to throw in my 3 cents to Fortran vs C argument. (I won't be commenting Fortran vs Python thing because it's completely irrelevant and these two languages serve completely different purposes.)

I started my PhD project a year ago. Before that I had some considerable experience with programming, particularly in C, Python, IDL, PHP and several other languages. I decided to learn Fortran 2008 as my major language (I'm mainly solving PDEs) and I think it's a wonderful choice for this purpose.

I think the proper version of your question "Why they keep pushing young students to be stuck with Fortran, while those students could learn a new and fascinating language the improve their productivity by orders of magnitude?" should be rewritten as "Why they keep pushing students to be stuck with C, which is a horrible choice for numerical computations in terms of readability and code maintainance, if they could learn Fortran 2008 -- a modern language, as fast as C, with built-in array handling and multi-processing mechanism?".

I think Fortran is way better for array operations and number crunching, while C is preferable for binary trees and other logical algorithms. So I guess it's not "being stuck with Fortran", it's "choosing the best solution available which Fortran is".

Dominik, the original question was not about Fortran vs. C. And the original post also didn't just ask about Python vs. Fortran either. Instead the question was about using Python together with NumPy and SciPy instead of Fortran. There is research showing that scripting languages, like Python, have fewer lines of code and as a consequence fewer errors (as the number of errors per line is almost constant among all programming languages). So, Python with NumPy and SciPy helps to write your code faster (as in it requires less time to write the code), is more robust, and it is almost as fast as Fortran. BTW, using modern Fortran, e.g. Fortran 2008, will decrease performance significantly if you are actually using modern features (I have seen benchmarks showing a performance drop up to a factor of 100 compared to 'old' Fortran). In these cases Python would even be faster (because internally NumPy and SciPy is highly optimized Fortran and C).

Furthermore, you should distinguish between C and C++. I agree with you that plain C is not a good choice for numerical applications. However, C++ has libraries available which provide the same syntax for vectors and matrices as in Fortran and allow for more sophisticated optimizations than what Fortran compilers actually could do. The secret for any programming language is that you should rely on libraries as much as possible. They are well tested (so they'll have few bugs) and mostly optimized. One huge disadvantage of Fortran is that it does not have many libraries, especially not for common tasks.

I agree with the original post that 'being stuck with Fortran' is the right wording. Built-in arrays is not a good argument for Fortran because other languages provide capabilities which are comparable or even superior (even if it is through libraries). Additionally, it is impossible to combine fast Fortran with modern Fortran. You have to make a choice (though you can mix it for different parts of the code). Other languages provide modern language features without any loss of performance (or with moderate loss compared to 'old' Fortran). I prefer readable/maintainable code (even when the main requirement is high performance) which Fortran, in my opinion, is not able to provide (in my current job I am working on a simulation software written in Fortran).

@Hossein: Sorry, I don't have any details. I have seen this live in a Fortran course held by one of the Fortran standardization committee members. This had to do with how you hand down arrays to subroutines. Initially, just plain fixed size arrays, then pointers (not too bad), then types (struct of arrays), down to full classes (object oriented programming). This was tested with gfortran.

Hello Simon,

I perfectly understand that Python makes your code shorter. I am not denying that for operations that can be represented by matrices, NumPy is an excellent tool, since its core is written in Fortran (as someone mention), yet you don't have to deal with all issues that low-level languages have. I use NumPy and PyLab as the main tool in my work, mostly for post-processing models computed in fortran (my case is not easy to parallelize, therefore I stick to F2008 to generate the data, and then handle it in python). This is why I'm saying these languages serve completely different purposes and there's no point in comparing them.

However, I cannot believe that slowdown you're speaking about. I have rewritten my code to C one day which caused about 1.5x speedup in performance, but this came at a cost of code readability. Of course you can't get any faster than C even using Fortran. The "more abstraction in Fortran helps compiler do its optimizations" argument has not been valid for years since compilers got so intelligent they can optimize the C code even better. Why I decided to keep my project in Fortran rather than moving to C is the ease of use, maintainance, modification, debugging etc, as well as excellent code readability (comparable to Python+NumPy arrays). These "soft" factor are often missed, yet they are just as important as 1.5x speed difference.

And, last, I am certainly not able to believe that built-in Fortran arrays can be slower than object-based arrays in C++ that provide the same functionality and readbility unless I see this myself. Only then I might reconsider my language choices. 

Have a good day :)

Dominik

Hello Dominik,

C itself probably will not be faster than Fortran. However, for C++ there exist matrix/vector libraries that make use of so-called expression templates. Blitz++ was the first library to use it and Eigen is one of the most well-known modern libraries in this area today. I am not entirely sure in which case which library (even BLAS or LAPACK) will be the fastest.

The advantage of expression templates in this context is that these libraries can optimize for the order of individual multiplication instructions. Especially when matrix multiplications are chained expression templates help reducing the number of nested loops. In theory, Fortran compilers could do the same, I guess. But, so far I haven't heard of it.

Speed always depends on your particular application. From my experience, the Intel Fortran compiler produces the fastest code. The Intel C++ compiler can produce fast code, but only if you don't use object oriented programming (tested with version 14). With g++ you can use any feature of C++ without a major performance hit. But, it's baseline is slightly lower from Intel's Fortran compiler. And gfortran is on par with g++ (haven't tested modern Fortran myself).

You might have heard of libraries like MKL or ATLAS which use traditional approaches (Fortran-like). Here are some benchmarks for Eigen:

http://eigen.tuxfamily.org/index.php?title=Benchmarkand Blaze:

https://bitbucket.org/blaze-lib/blaze/wiki/Benchmarks

Unfortunately I couldn't find good benchmarks comparing with Fortran. There is, however, an old article about Blitz++ vs. Fortran 77:

http://www.drdobbs.com/cpp/scientific-computing-c-versus-fortran/184410315?pgno=1

You can find the figures when clicking through the pages.

Have a good day as well

Simon

Hello Simon,

Python with NumPy / SciPy is NOT "almost as fast as Fortran". It is much slower, and the API really isn't that nice anyway.

Python+NumPy is popular because for a lot of the less demanding tasks (e.g. a lot of data analysis) it is fast enough. But these tasks were never done in Fortran anyway. Those tasks are traditionally the domain of Matlab, or in astronomy a language called IDL. But anything that actually requires performance is simply outside the scope of NumPy.

Also don't forget that Fortran is already a high-level language. Porting code from Fortran to Python+NumPy doesn't make it that much shorter.

If you want a scripting language to replace Fortran, have a look at Julia. It is faster than NumPy and it actually has a nice syntax that was designed for scientific computing from the start. It's still not as fast as Fortran, but it closes the gap a lot. I recently considered Julia for a hydrodynamic simulation and the Julia version of the code was faster than the default compile with GFortran, but slower than the default compiles from the Fortran compilers from Intel and PGI. Then I re-compiled the Fortran again with optimization flags and then it was 2x faster than Julia. The fact that Julia can get in the ballpark of Fortran is impressive. NumPy can't really do that, unless your program works mostly by calling external libraries like LAPACK, in which case it doesn't matter what language you use because it's the library that's doing the work and not the language.

Finally, "being stuck" is definitely wrong; extremely wrong. A lot of physicists already know Python+NumPy. I certainly do. I am comfortable with Python/NumPy, Julia, C, C++, Fortran, and more. Instead of starting from the position that there is a fundamental need to replace Fortran, please consider that it might often be the right tool for the job. Python does not replace Fortran for the reason that Python does not replace Java and Python does not replace C++. Different languages offer different features and trade-offs and some times people will legitimately look at alternatives and choose a language that is not Python.

Dear all,

I encourage you to read this nice article about Python which underlines my point of view:

Yes, Python is Slow, and I Don’t Care

A rant on sacrificing performance for productivity.

Cheers

Giovanni

https://hackernoon.com/yes-python-is-slow-and-i-dont-care-13763980b5a1

Dear all,

again a supporting point of view:

Why Astronomers Love Python And Why You Should Too, Youtube video

Giovanni

http://youtu.be/W9dwGZ6yY0k

Because most of the data is available in the fortran language. Users from the beginning have used fortran language. The conversion from Fortran to other will be difficult. Though, python like languages are used nowadays.

As a Fortran programmer most of my life, I had not considered that expressiveness was one of the best aspects of Fortran. But on reflection, I think there is a lot less line noise in a Fortran program compared to Python and C. Most of the differences here are superficial, such as extra square brackets for multidimensional arrays, the lack of curly braces/more use of english (although this also becomes a burden), and the way arguments are listed below the subroutine line, enabling INTENT, PURE, and other details to be documented clearly (the one line C/C++ style is just not very readable).

Having said all that, nowadays modern C++ with libraries would be acceptable for me, even for speed, but not convincing enough to leave modern Fortran, unless I had to interact with non-numerical or GUIs. But not everything comes down to compute speed, eliminating an d detecting bugs i.e. maintainance is a huge consideration. And as I said, on reflection, modern Fortran is just really nice and pretty for coding maths. There is a huge amount of reusable high quality code out there.

Standardization is a big issue as regards a language. I write codes that I design and expected to work for half a century, if not more, so I don't want to deal with stability and standardization issues in this situation. The lifetime of codes you write may not be like this.

The advantages of templates is highly overstated, in my opinion. Templates are easy to do in Fortran with include statements and macros. This is a much easier way to do inheritance for beginners. The "is-a" and "has-a" problems just disappear. I've never understood the "part of the language" argument as regards templates. In addition, with Fortran, you can use the same code in different objects using the PASS() passed-object descriptor. The only time templates become very useful is when you are coding huge projects, making very high level abstractions e.g. like Blitz++.

It is simply not true that "compilers got so intelligent they can optimize the C code even better". I don't know why this statement appears so often, and is stated with such conviction. It is almost never true for me, in practice. And in theory, it depends very much on the compiler, and to get code as fast as Fortran in C you may have to help the compiler by avoid aliasing, and make use of the volatile keyword. For specific application libraries, C is undoubtedly better for writing the low-level compute kernels, since in most cases the OS is written in C, as is done in the modern Flame libraries. But these professionally written libraries have APIs for Fortran and C, and no computational scientists write this stuff -- these are made by computer scientists and mathematicians. (Thanks guys, keep up the good work).

It is true that much better designed compilers are now available, such as LLVM. I very much hope that those guys can make a Fortran compiler as good as gfortran, I think they are nearly there. Not yet though. This is certainly not the "compilers got so intelligent they can optimize the C code even better". In fact, it clearly points out the speed advantages of *not* doing that.

Python is great for doing little ditties, for quick turnaround for algorithm exploration, and transforming data into useful input for further analysis. In many cases, especially in a time-limited situation, it will do the job. But it is not the optimum language for bespoke quality numerical software for particular applications. It's better then to have Python wrappers. These days, anyway, you can link Python to any (old style) Fortran subroutines easily. A very sad point is that it is hard to link Python to modern Fortran arrays and derived types. If you want to use Python for big quality jobs, you will have to be more disciplined in the programming, design, commenting, and to control errors, you really need a typed language, in my opinion.

I can't recommend Julia either, for numerical work. Julia is really great, it is modern, but I reject it for long term work because of standardization issues.

There is only two languages I would currently leave Fortran for, and it is too early to do so. The first is Chapel. It is the ultimate compute language. I am only waiting for Cray to throw more money onto that. I may very well switch over in the near future. It is so well designed. The second is Haskell, only because in principle, it can do everything Julia can do. In principle. In practice it is nowhere near what is required for numerical work, but it is fantastic for symbolic manipulations, and this mathematics part high-end part of numerics.

Fortran is just a lot faster than numpy, and also more adaptable; numpy or matlab for that matter are sometimes difficult to adapt to a problem (like solving one 1D differental equation). It is well maintained and is in constant evolution (the last is Fortran2018). . There are some critics like not being able of a quick interactive session. Or to have an easy interface to GPU. But even that will probably be solved in the near future. Have a look at lfortan. https://docs.lfortran.org/

The first question is 'What's wrong with Fortran'? Is Fortran 'broken' and beyond fixing at that? If not, why move to Python? Why move to a much slower OO-language to run procedural code? Because it is fashion among people doing very different work? People in science spend their time doing research and computational aspects are very important, but not the end, just like a soccer player must have speed and endurance, but that is not his main job.

If you follow current #AI developments, you notice a dramatic shift towards Python and the named packages. Any good programmer can write code in any language, however also any good programmer will make a good decision of what is acceptable for process, team working, future, and quality, verification and validation, documentation, etc.There are so many aspects, and specifically persons should take much broader consideration / perspective before deciding what is the right language, not just speed, or because it is cool, or because it worked because it glued some really deep complexity together. Thanks for having opened this discussion.

Related: https://www.fortran90.org/src/faq.html#what-is-the-advantage-of-using-fortran-as-opposed-to-for-example-c-c

Further reference: this is an excellent(!) introduction to Fortran:

https://ethz.ch/content/dam/ethz/special-interest/mavt/energy-technology/renewable-energy-carriers-dam/documents/teaching/Lectures/Additional-material/03530_Computing_with_Fortran_by_Haselbacher.pdf

One advertised advantage of Python is the simplicity of syntax. But being simple can be a wrong attribute if a student learns to program for the first time. "Implicit none" approach of Fortran with strict syntax will serve better for a beginning science student and he can easily learn to code in any language later, with the strong programming foundation gained.

@ Ludwig Schreier : We are not talking about which language is better in general, but which one is better for scientific work and the hands down answer is Fortran because of speed which is of primary importance. Imagine a metereological application where solving the equations happens after the prediction interval. And this is not just for the 'final' results, but also for debugging and testing: When running tests to check code aspects I want them to run fast, not wait a day per test. As for AI, do you seriously want to compare a clustering or neural calculation in Fortran vs in Python? I can do this in R or Weka or Rapidminer also, which may be easier to use but not if speed is your concern.

Fortran 2018 is backwards compatible with Fortran 2008, and Fortran 2003, and Fortran 2000, and Fortran 1995, and Fortran 1990, and (mostly) with Fortran 77 and Fortran IV.

Python 3.0 is not backwards compatible with Python 2.7.

What will happen with Python 4.0?

In terms of simplicity and availability, Python is very good. In terms of performance, Python is adequate for small projects but very far behind in High Performance Computing.

Modern Fortran (at least as recent as Fortran 90) is an excellent language, take a look: http://www.hpc.lsu.edu/training/weekly-materials/2014-Spring/Fortran-Spring-2014.pdf

Hi Ben,

I'm going with laziness. FORTRAN is well established, strongly typed and very easy to use. Why should I devote any time learning a new language when the one I truly understand does the same job (for my purposes) without requiring me to learn a new way to do the same old thing?

Hi Brad -- Good to hear from you -- it's been a long time! I hope you're enjoying retirement -- I've still got a ways to go.

I've got to respectfully disagree on the laziness as a major cause, but my evidence is anecdotal: all Fortran programmers I know also have multiple languages under their belt -- most are using Fortran because its array processing is cleaner than C pointers and FOR loops. My problem with Python (beside slowness) is the need to re-write everything at the whim of the Python gods. I'd like to see someone do an estimate of how many man-hours are being wasted because of Python 2.X and 3.0 incompatibilities. I know my team has lost man-weeks of effort over this self-inflicted absurdity. Based on our experience over the past couple years, I will never commit resources to any major long-term efforts in Python until the Python gods provide assurance that ALL future Python versions will be 100% backwards compatible with packages written in Python 3.0. Until then - Python is a nice demonstration and prototyping toy, but our long-term codes will be in Fortran, C, or R. Thanks for listening to my rant.

Hey guys. nice comments. I just want to mention add to Ben that I have never had backwards compatibility using R. Most of my code is done with base, data.table and sf.

I have to go with reliability, compatibility and simplicity. Many age-old scientific codes written in Fortran remain alive because they do the job. Fortran is also somewhat simpler to digest than C, in particular if you are not interested in having a deep relationship with your computer. I also agree with Ben, Python is risky and there is too many open ends on its development. As Sergio, I would vouch for R as a high-level language (lovely for post-processing my results), but for performance, I can clearly see why so many of us stick to C/Fortran. Another good reason of why Fortran is alive and well, is that some very large communities (climate science, for example) rely on very well established Fortran codes. They are not in the business of throwing away 20+ years of testing their implementations.

From my experience, the only reason to stick to Fortran is the already written code. When a scientist has a code than compiles and runs, maybe written in the '80s so that it will require a lot of effort to move to another language, the options are very few.

If the code works well, fulfills all expectations, it is fast, efficient, continuously updated, why to change to another language? The only reason for swapping to another language is functionality. If there is something you want in your code that Fortran cannot realize, that's a good reason for seeking another option. However, in science, I do not know what Fortran cannot carry out.