That’s a good one. There are similar older articles, e.g. this one from Linda Wharton titled “Should C Replace FORTRAN as the Language of Scientific Programming?”
There have been similar articles on C++ versus Fortran, e.g. this one:
The author is Todd Veldhuizen who pioneered the use of C++ expression templates for linear algebra (see Arrays in Blitz++ | SpringerLink). Since these papers were published, Fortran also has a few new tricks up its sleeves. It would make an interesting case study to revisit these examples.
The Fortran Wiki Articles page has a “Fortran Advocacy and Language Comparisons” section where the Wharton and Arabas articles and other articles and blog posts are listed.
OK, but all of these are different from “don’t run well on modern computers”: they simply cannot be compiled and run as they are on 64 bits machine, and they require some porting. But this has little to do with F77 in itself, and there are certainly C codes from the same era that have similar issues (I remember one, not in HPC but in a technical field, that was wrongly assuming that an int was equivalent to a 16 bits short, because it was the case with the compiler the original developer was using).
It looks to me that you are making some confusion between the languages and the compilers. To write code that has chances to stay around for decades, the first thing is to stick to the standard as much as possible to ensure its portability. Then, whatever the available compilers in the future, it will compile.
“whatever the available compilers in the future, it will compile”. Don’t agree. Our code is half-million lines and was compiling and executing perfectly on gfortran, solaris, Intel and AIX. Recently, we had to make extensive modifications for supporting flang-new. You could say that standard code never needs such correction, but a code is never 100% standard. In fact, I found Linux and gfortran far too permissive (this is also true for gcc). This is why I maintain non-Linux systems alive for QA validation. I would also recommend to validate any Fortran code against flang-new. You will be surprised…
I am still a somewhat new Fortran user (required for my job), but I come from using lots of Python and some C during my PhD. This forum has been a great source of information as I’ve been learning. But I’ve noticed that a lot of Fortran experts are frustrated when people talk about Fortran being outdated or not as functional as other ‘modern’ languages. And I think a big part of this perception is that Fortran is ‘hard to use’ in the sense that there are not very many good resources on ‘how to use’ Fortran. For a vast majority of scientific programmers, ease of use is much more important than performance (by this I mean that many scientific programmers will save time by writing code in Python using NumPy rather than writing it in Fortran).
A new scientific programmer may want to read a yaml config file (or whatever format). In python and C, this is a readily available feature. But fine you figure out how to use someone’s Fortran yaml reader from github or implement your own. Then you want to use an array constructor so you google it and a bunch of the first results are confusing; a new user may be unsure which of the options from the first search result is the best one to use. However, the results for similar constructs in Python and C are available with lots of examples. Slightly more complicated array operations are conveniently provided in standard libraries in other languages. And, again, fine you figure it out in Fortran. However, now a simple task of reading a file and doing some simple array operations has taken a significantly longer time than it would in Python. This is not necessarily a bad thing, but it is a hurdle.
Many new scientific programmers are programming in order to do science. They are not learning how to program and then doing science.
I think there is some great work being done with LFortran and the Fortran Standard Library. When those tools are in a production state, I think Fortran will actually make a lot of sense to teach new scientific programmers. An added benefit of having a Standard Library (with accompanying documentation and tutorials) is that it will help a lot of modern Fortran development centralize around a set of best practices so that there is more consistency (and therefore more ease of use) between packages and libraries developed by different people.
Anyway, just my thoughts as somebody who has been on the Fortran learning journey for a couple years.
Yes, and that’s accentuated by the performance expectations, job precarity, and pressure to produce “science output” that is narrowly defined and keeps getting more dimensions (in addition to research articles, there’s now outreach and demonstrable impact on international policy and economy). Unfortunately, producing and publishing clean code requires time and usually doesn’t count toward anything (unless your lib revolutionises the software world). However, I will make the point that adopting some habits and tools from the software development world (e.g., git) benefits the science, too, and can be introduced even in this environment. It’s perfectly valid (and right) for any scientist to prioritise science over software development, but it makes sense for the science to adopt some things.
I think Fortran will actually make a lot of sense to teach new scientific programmers.
Absolutely. I am looking to re-introducing it here, and LFortran, stdlib, fpm and some other new projects can help with this (and help me make a case for it). Please feel free to share what you - as a scientist and someone who’s somewhat new to Fortran - feel the top priority should be (in tool and learning material development) so Fortran would feel equally or more attractive to young scientists than Python, for example.
-Wall is always activated in my makefiles. Here are a set of issues: (1) call the same subroutine where an argument is the first element of an array and where this argument is the array is forbidden in the same subroutine. (2) C-interoperability with logical(len=4) is forbidden. You should use logical(len=1). (3) Some user-defined types may have errors not detected by gfortran or other existing compilers. In every case, flang was correct. Make the test by yourself. I also noticed that flang-new is slightly faster than gfortran on my MacBookPro. Finally, I had no problem with python3 interoperability using flang and clang. Recommended.
I started looking at low-cost alternatives to Wolfram Research’s Mathematica and ended up in Julia. The speed’s amazing and there’s enough of a community to support a wide range of libraries that I’m interested in. I had intended to stick with a two language solution where Fortran handles numbers and Julia handles data processing & presentation.
While Julia can call Fortran routines, and it does so quite easily, there is a pain point if arguments use structures. Enough pain that it may be better in the long run to translate the Fortran to Julia.
AI is a great assistance when translating the modern Fortran to Julia. But it’s not automatic.
Well, I’m embarrassed. I misread the original quote as “…doesn’t run well on modern compilers”, which would be a silly thing to say, and I responded with what I thought was an equally ridiculous statement. It was just dumb, and misguided, joke.
That’s precisely my point: do not use non standard features if you want to maximize the chances to be portable between platforms and with future compilers. Some de-facto standard features -albeit non officially standard- can be acceptable, though.
BTW, I’m somehow surprised that a code that was fine on a variety of platforms and compilers did require “extensive modifications for supporting flang-new”.
Linux has nothing to do with that, it’s only the compiler. The NAG compiler is available on Linux, and is known to be very robust to detect non conformant codes.
Anyway, it’s always a good idea to test codes with different compilers, as some of them can detect issues that some other ones ignore.
This can be seen as a bad practice nowadays, but I’m pretty sure that it is NOT forbidden. Before F90, this was actually the only way to pass for instance an arbitrary column from a 2D array, without having to copy it in a 1D array beforehand.
gfortran does catch this one:
use iso_c_binding
interface
subroutine foo(x) bind(c)
logical :: x
end subroutine
end interface
end
with gfortran 14.2 and the -Wall option:
4 | subroutine foo(x) bind(c)
| 1
Warning: Variable 'x' at (1) is a dummy argument of the BIND(C) procedure 'foo'
but may not be C interoperable [-Wc-binding-type]
Note that the right way is not to declare logical(kind=1), but to declare logical(kind=c_bool))
I’d be curious to know what error exactly flang caught here. I tried the following program, but it is accepted:
subroutine alias(a,b)
real :: a(*), b(*)
print *, a(1:5)
print *, b(1:5)
end subroutine
real :: a(10)
a = [(i,i=1,10)]
call alias(a(1),a)
end
I think flang does catch some corner cases which other compilers don’t ; but that doesn’t mean those usages were “standard” to begin with. Which is why it is always good to check with multiple compilers if possible.
The inability of some compilers to flag this error [(an illegal declaration)] is unfortunate, but it also indicates an important aspect of portability. Languages have dark corners where practice varies – bitfields in C and C++, for example – and it is prudent to avoid them. Use only those features for which the language definition is unambiguous and well understood. Such features are more likely to be widely available and to behave the same way everywhere. We call this the mainstream of a language.
$ cat test.f90
real :: a(10)
a = 1.0
call test(a)
call test(a(1))
end
$ flang -c test.f90
./test.f90:4:1: warning: Reference to the procedure 'test' has an implicit interface that is distinct from another reference: incompatible dummy argument #1: incompatible dummy data object shapes
call test(a(1))
^^^^^^^^^^^^^^^
./test.f90:3:1: previous reference to 'test'
call test(a)
^^^^^^^^^^^^
Note that this is just a warning.
My experience with flang is that it is very forgiving about accepting non-standard code if it has a reasonable interpretation, often shared with other compilers. Using -pedantic and -Werror makes it much stricter.
The warning goes away if you add external test. I guess the reasoning is “the programmer has asserted this is an external routine, so they’ve checked it is safe to pass a simply contiguous array or an array element designator to this procedure.”
You got my point. This is just a warning, but occurring thousand of times on my code, before making corrections. Too many warnings means that you could miss important ones.
I don’t know… You started with codes that “do not run well (or at all) on modern machines”, and with “we had to make extensive modifications for supporting flang-new.”, but at end we are only talking about some warnings in fully conformant codes, which do not prevent the codes to be compiled and to run as expected.
Don’t get me wrong: using external when implicit interfaces are there, not passing an array element where an array or array section is meant, etc, etc, are certainly good practices when writing new code, or in the process of code refactoring, but this is not required when using old codes as they are.
I don’t know for flang, but with ifort/ifx for instance one can selectively enable/disable specific warning messages.
My half-million lines of code had ~12 real errors and many thousand of warnings. Il is important to limit the total number of warnings (due to QA issues) so that we see important ones. I don’t want to selectively disable warnings. Correcting everything I could took me about two weeks. And, no, I don’t want a LLM to modify my code. I want to keep it reading as a book.
