Yes, the GitHub repository is intended as a place to collect and incubate ideas for future revisions. But we have no shortage of ideas - what we are short of is people willing to sit down and write papers that form the basis of adding a feature to the language. Even during J3 meetings, when most of these papers are written, only a few members regularly write the specifications, syntax and edits papers.
Absolutely, though Iâll note that this was also done for 202X, with a widely publicized survey and frequent discussions in multiple venues. I have written and spoken about future features in my Doctor Fortran blog and in presentations. As Iâve said before, though, the âcommunityâ is much larger than any of us can address and certainly larger than the audience for this site and your GitHub site.
I donât really see the lack of community support to be a gating factor here. What would be great is if the proposals in the GitHub moved past âhow about this idea?â and into at least making a start at figuring out how such a thing would be integrated into the standard.
ok, great. Iâm familiar with git and will try my best to bring our patches into the main branch. How should we proceed?
While I canât pay you, I can also offer to help you with learning git. I also switched from svn, and despite the steep learning curve and sometimes unlogical syntax, I did not regret this switch for a second.
Regarding certified code: Compilers might have regressions, hardware might behave differently than expected. So switching to a new version of gfortran, changing hardware, etc. would need to trigger the expensive review request if the review process is really meant to detect bugs. Probably these âcertificationsâ just serve as an alibi for legal reasons. Unit tests are standard in 2021. Having a code for nuclear energy without a test suite that can cope with a small syntax change is just careless. If no one dares to touch a code even for a minor change, I would consider it broken.
Thanks @sblionel. It looks like you agree. You already have at least two other people who offered help (Milan and I), but I am sure there will be more.
Are you ok with us starting an effort to publicly discuss a draft of a list of features that should go into 202Y? If you give us a green light, we will first come up with a plan how to do that, then discuss with you, get you on board with the plan and then do it. It looks like there is enough time to get solid back and forth discussion with the community in the âlargeâ sense and to get consensus in the large sense. The WG5 can then take it as a starting point (not binding, but hopefully influential). Obviously, if we fail to get community consensus, then WG5 will do their âbest judgementâ. But I would like to try.
If you want to put together a list of features that have been suggested, to encourage discussion, fine. Please do not represent this as âshould go into 202Yâ or as something representing WG5/J3.
WG5 will draw on many sources of feature suggestions - the more early discussion, the better.
Thank you. Yes, this would not represent WG5. The actual final list would be voted upon by WG5 members, so if somebody wants to influence it, they would have to join WG5.
However, the list would be about what the community would like to go into 202Y, that is the whole point. Can you elaborate a little more why we cannot discuss that?
Sometimes âshouldâ is used to make a prediction, for example when one says âIt should be sunny tomorrow.â The phrase âX should go into 202Yâ could be interpreted by outsiders as âit is likely that X will be in 202Yâ. So proposals can be discussed here, but I think @sblionel wants it to be clear to the Fortran community that any consensus reached here would still not be binding on J3.
I see. Yes, that is fine with me. I didnât realize âshouldâ could imply that WG5 is bound by this. As I said above, WG5 is not bound by this, but I simply want the community to help create a plan for 202Y, to be involved from the beginning. WG5 does not have to follow it, but since multiple people from WG5 will be involved, hopefully including the chair of WG5 , then I am hoping WG5 will be âinspiredâ by the list.
I totally agrree. Unfortunately, this is pretty much the norm in nuclear industry and academia. Iâve made it my mission to find these codes and convince their owners it would be cheaper for them to pay me to fix them than to continue on with the costly âreviewâ process they currently have, because there is no such thing as software that doesnât ever need to be changed.
Iâve seen dozens of examples of codes that went through the following progression.
An engineer (or researcher, etc.) needs to do similar calculations on a regular basis. They just learned this new Fortran programming thing, so they write a program to help them do it faster.
They overhear a colleague lament that they wish there a quicker way to do the calculation, and hand them their new program. This continues to happen several times. Tweaks and new features get added along the way, often without a real understanding, and never reconsidering the original design
Eventually (often long after the original developer is gone) a manager catches wind of this program and assigns someone to âownâ it
Quality Assurance finally hears about it, and puts a stop work order on all these calculations until someone can perform an official review of the program. This ends up being very costly due to
a. The stop work order preventing billable work from getting done
b. What ends up being an arduous, manual, black-box testing effort
This becomes the defacto âspecificationâ for what the code is supposed to do. No one dare investigate further, learn how the code actually works, or heaven forbid make changes to the code, lest they have to repeat step 4.
Throw money money at compiler vendors to make sure we can continue to compile our already broken code, lest we have to admit we donât actually know how our code works.
If you ever want a chance at breaking backwards compatibility in Fortran, these are the people youâll have to convince. Iâm getting pretty good at fixing these codes, but I can always use help finding them and convincing people the effort is worth it.
A Hacker News thread has become a discussion of Fortranâs backward compatibility. I think the following comment from BlackFly puts it well (although I donât support deleting old features from the standard)
People will joke about the primitiveness of Fortran as long as they are required to preface every module and program with implicit none. Also, every time they pick up lapack and need to specify the âleading dimension of Aâ they will recall how Fortran had itâs roots in a language without dynamic memory allocation and how theyâre still living with that legacy. Fortranâs legacy leaks all over the place: you rapidly get a feel that it is something which is old and creaky, even if it is actually old and rock solid. The ergonomics are very much not modern, though, but as with all discussions of ergonomics, that is going to depend on how you like to hold your tool.
Not[e] that other languages which have widespread support also have similar historical mistake leakage. Null vs Optional in Java comes to mind. The python 2 â 3 debacle was a similar sort of âhistorical mistake correctionâ but the breakage of backwards compatibility lead to quite some polarization. Actually, in python 2 â 3, the python core developers tried to fix a historical defect that fortran still has: print as a keyword vs a function.
The purpose of print is not to return a value, so I donât agree that it should be a function. Maybe a subroutine, if one were starting from scratch.
The part I take exception to is your use of âthe communityâ. What you mean here is the small set of motivated users who are proposing features in the Fortran Features GitHub. This is not representative of the Fortran user community as a whole or even a large part of it.
I absolutely encourage attempts to get more Fortran users involved in suggesting and discussing possible features. What I donât want is any implication that these are leading contenders for inclusion. You could say, âHere is a selection of the ideas some of us have come up with - what do you think of them? Do you have ideas of your own?â Iâll note that there are lots of features from the 2017 survey that didnât make the cut for 202X and many of them would be considered for 202Y.
Yes, I agree that the community here is not big enough to be representative. But it is not small. The @fortranlang Twitter account has over 1500 followers. Thatâs not a bad start, I would not call that small. But our (my) goal is to grow this community to be comparable, say, to @rustlang, which has 80,000 followers, or JuliaLanguage which has 20,000 followers. (Yes I know Twitter is not everything.)
I know the conversation has drifted away from NEK specifically, but I for one am extremely excited by the announcement of Neko! Thanks to @pcosta for posting the ArXiv link, and if anyone has any more information about Neko (release date, etc), Iâd love to hear it.
With regard to NekRS specifically, I think a significant factor in the switch to C++ was just the fact that Tim Warburtonâs group (the ones behind the OCCA kernel language) arenât really Fortran users. The main goal of NekRS, as I understand it, was to be able to target certain current and upcoming DOE computers that are accelerator based, hence the interest in OCCA.
The NekRS code includes code from my teamâs libParanumal library. We wrote that code in C/C++ and developed performance portable OCCA based implementations to perform offload computing tasks.
fwiw OCCA also has a F90 interface ( example code )contributed by a community member after the libParanumal project was well under way. However, the OCCA compute kernel language is still C-like. Some years ago we also had a limited fortran-like kernel language, but there was no interest in using it so it was deprecated.
The Neko project is very interesting, and also uses some kernels derived from those we built for libParanumal, but appears to be in active development and has not been released yet.
It was not my intent to âreplaceâ Nek5000 fortran code with C/C++/OCCA. However, the code we developed within my team has been adapted by some in the Nek community as a platform to build NekRS to explore performance at scale on emerging architectures. The Nek5000 and NekRS codes are interoperable and each coexist with somewhat different use cases and capabilities. The contributors to those projects can better explain their plans than I can.
I would just like to say, Fortran being my 5th language or so and me now choosing to write my programs in it (that I want to go fast anyways; python otherwise), this is one of the biggest reasons why Iâve moved to it. Modern Fortran is simple, but [mostly] elegant and fast. Iâve done a couple Modern Fortran tutorials in my community, and people are impressed with how nice to read Modern Fortran is compared to what they think of as Fortran. The problems I encounter nowadays are mainly ecosystem (which fpm seems to be working to fix), and history - if I have an error to look up, or functionality to look up, I often encounter old F77/F90 material/solutions which are incomplete or inelegant or both.
