Many people here love to reason over dwindling fortunes of Fortran. So do I. And I have come up with some reasons on my own. Hints of it are already there in some of the threads here. But, I will put the case in a concrete and explicit form. I may sound ignorant at times. Please educate, when I do!
I think Fortran is following an old model of language development. One in which new features follow from a standard document to the compilers. Once in a while, a small group would meet to anticipate future requirements of the community, based on some limited feedback and no concrete implementation/prototyping/field testing, and dictate how the language looks like in its most recent form. The standard language remain a piece of document for many years to come, till some of the compiler teams catch up . Sometimes they will realize, while reaching there, that a new feature is not good for optimization. Users may not find a feature very useful and will just ignore it, or they may find a feature which should not have been there. But, the ship has sailed!
Modern languages on the other hand either have a complier/interpreter as their standard. The standard follows from the implementation, not vice versa. The case of Python, Rust or Java is clear. Even C++ has g++ as gold standard. Features they accept in the standard are already a part of the compiler extensions – tried and tested by a large number of users.
This brings me to the second point. Do you think it would have been better for Fortran if more effort was focused on an existing compiler, gfortran has a good case, than creating newer ones? Is it possible for the community to first get experimental version of future extensions in the compiler before they vote for them? I see no point in documenting new features while the compilers makers struggle with their backlog. Can we allow them to get ahead first!
Potential features of Python are debated as PEPs and approved before they are incorporated in CPython:
PEP stands for Python Enhancement Proposal. A PEP is a design document providing information to the Python community, or describing a new feature for Python or its processes or environment. The PEP should provide a concise technical specification of the feature and a rationale for the feature.
A danger of a standard following an implementation is that it may just ratify bugs. If the implementation has odd behavior, do you just document it in the standard, or do you try to fix it?
Whenever there is a new Fortran standard with many new features, such as Fortran 90 or Fortran 2003, some compilers get left behind, so the number of compilers is automatically winnowed.
We need three compilers: one to catch all compile-time and run-time errors, one to produce excellent object code and one to hack with for experimental features. We have good coverage of the first two categories and need some more strength in the last one.
Thanks for telling about PEP. Of course every feature incorporated in the compiler must have been debated at some level. I see two cases for languages:
Languages like Python, Rust, Julia or D: Kind of privately owned. There is no imposed ISO standard. The main compiler developers are responsible for the standards. There no reason for the compiler to lag.
Languages like C++: There is a standard divorced from compiler developers (with some of their representation, though). Chances are compilers will fall behind, as is true for Fortran. But in case of C++, g++ team is so swift that they get even features under proposal implemented. Allowing stadard committee atleast some realtime feedback before finalization of standard.
I am also concerned about spreading of talent and effort over so many compilers for a small community like ours.
No. The ones in the first two categories are clean-room, closed-source, proprietary, with proven track record. That’s no place to hack experimental features.
The number of Fortran compilers that are unique seems to be declining. Traditionally, companies selling computers or processors (Cray/HPE, IBM, Intel, ARM, …) had compilers to “show off” the performance of their hardware. As hardware vendors decrease in number (buy-outs, mergers, …) the number of such compilers also declines. Unlike languages like Python, performance is critical for Fortran, and hence the competition. And at least two of the hardware-vendor compilers (Cray/HPE and Intel) are essentially F2018 compliant already.
The argument for consolidation and pooling of programming effort might make more sense for an open source “community” compiler like gfortran. The gfortran gang has some very good programmers, but they seem perpetually under-staffed and face challenges in keeping up with the large commercial compiler efforts in terms of standard conformance.
Is there a way to access Cray Fortran compilers like Intel’s? What systems have the Cray compiler installed? I have always heard of Cray compilers ever since I came to know about Fortran. But I have never had a chance to work with it. I assume it is only available on specific supercomputers (That may explain why it is hard to find and access in general). Thanks in advance.
Yes, as I said many times, the trend has to be reversed: instead of the committee driving new features, it should primarily be the compilers driving new features and committee just standardizing; or the committee proposing new features, implementing them in a compiler, let the community experiment with it and use it, and later standardize it.
If you have time and interest to help us out with LFortran, we welcome any help. I can get you started. I’ve already used it to prototype a new feature for the committee here:
Depending on your status and country, there could be a Cray machine that is available for researchers to improve their codes, that is ran by a national agency. In the UK at the moment you can try an Arm Fujitsu A64FX Cray machine called Isambard and the AMD EPYC Cray machine Archer2.
I have exclusively used TACC supercomputers over the past decade, and all (major) TACC clusters are Intel architecture. So my experience is limited to GNU and Intel Fortran compilers, which I am trying to expand right now for software portability tests.
It seems bizarre that I never noticed the presence of two environments on ls5. The default does not appear to be Cray. ls5 default environment has Intel compiler 17 installed which is rather old and does not compile some of the modern Fortran codebase. So I have rarely used it over the past two years. Will test the Cray environment once ls5 is back to production. Thanks for the note!
I am worried about the whole 80s Fortran Saga repetition with vendors just locking the status quo with their extensions that forced users to stay with their compiler.
Very unlikely in my view. Fortran does not have the central place it had then. Experimental usability features far more likely to come from one of the community compilers.
Thank you for the offer! I hope my schedule will somewhat ease out after this month. But, I am not sure if I have the requisite skills – always happy to learn, though.
Thanks! After Google announces which students got accepted on May 17 and if there are any for LFortran, then we plan to do an on-boarding for them and I plan to invite anybody who is interested. So I’ll ping you. It is not hard at all, I can explain the whole design in about 5 minutes and you will see that there are many places where you can contribute.
I think at the moment there are too many Fortran compilers. gfortran, intel (ifort/ifx), Cray, Fujitsu, IBM, Nag, Nvidia, AMD, Arm, Huawei etc. Some of these compilers use the LLVM infrastructure as the lower level IR for optimisations and codegen or use the Clang/LLVM compiler for C/C++. Hopefully, once f18 (llvm/flang) compiler reaches production the compilers/companies that use LLVM will switch to it and we will benefit from a larger community.
We should also explore whether LFortran and f18 can share some code.