@MarDie I agree with your overall sentiment. I think we have already discussed this at the phone call, but I am always happy to discuss more. I love discussing precisely this topic.
I have slightly different perspective on some minor technical details, but I agree 100% with you on the overall picture.
Yes, we have to implement tons of obsolescent (even removed!) features in LFortran, otherwise it won’t compile SciPy, or established production HPC codes. However, I am in close contact with the SciPy developers and they are willing to change the Fortran code so that it would compile with LFortran. They are also interested in modernizing the code, precisely as you said.
So there is no philosophical disagreement, but the work still has to be done. I will be able to tell you the exact answer in about a year, once LFortran can compile most codes, but so far at least implementing some of the old features is not that big of a deal, the majority of my time is spent implementing the new features. The old features do not seem too much of a lost time, or technical debt in the compiler. But once everything is done, I will be able to tell you if that is still the case.
unfortunately, the “normal” LAPACK is the only version that is available on all systems (e.g. on Ubuntu) without extra effort. So it is a natural choice to use it.
I would be optimistic that there are volunteers that would modernize important libraries if that is needed. But as long as there is no need or incentive, it will not happen. A hint of the sort “your code is not conforming to the newest standard” could nudge people out of their comfort zone. A similar thing has happened when gfortran enabled stricter type/dimension checking. Sloppy code now compiles only with -fallow-argument-mismatch.
What is motivating the SciPy developers to consider modernizing the Fortran code? Often the approach of Matlab/Octave, SciPy, and R developers is to leave working Fortran code alone, even if it is old-fashioned. What tangible benefits are envisioned to end users who will never look at the underlying Fortran and C code of the packages they use?
Sure some would try to do that. But so what? We’re going to lose those people anyway and their codes will die with them. Others will update their codes to modern Fortran, which is what we need going forward. It’s time to move on (long past time).
Re: SciPy. This is encouraging. Getting all that F77 code in SciPy converted to modern code should be a top priority of the Fortran community. It’s doing great harm to the perception of Fortran.
Thanks. I am counting on you @jacobwilliams and @MarDie to help with modernizing SciPy. I will be in touch in a few months. My first goal is to get LFortran to compile it. LFortran can actually convert the fixed form to free form already for the things it can parse. Converting to modules would be the next natural step, and so on.
Meanwhile, I’ve converted some of their C code to Fortran for possible inclusion in stdlib: see here. If we can get them to replace C with Fortran, then we are really moving in the right direction!
That Fortran is alive and in such widespread use today is a tremendous success in my view. Of course, we can speculate and debate endlessly what helped get it to this point. That Fortran is mainly used for old projects is a relative statement. All else being equal, it’s better if old projects build and run than if they don’t. And given that they do, a more relevant metric to look at is the absolute number of new projects being created. And that’s something we can improve (and we have already) with better tooling like stdlib, fpm, LFortran and other compilers, online resources etc.
I think this statement is too broad and general to be made as a black or white. There are many domains of science and engineering where either language is more dominant than the other, including for new projects. Like Fortran, C and C++ are also mostly backward compatible, so that property itself is not the differentiator.
Having maintained the list Fortran code on GitHub for a while, I can say that many projects
using Fortran continue to be created and maintained in the areas of astrophysics, quantum
chemistry and electronic structure, weather and climate prediction, the broad category
of earth science, and computational fluid dynamics, often using finite elements. Biological
systems are often more complicated than what chemists and physicists study, but increasing
computational power means that there are new applications of Fortran in biology and medicine.
Isn’t it the case that the code NEVER conformed to ANY standard but exploited the inability of compilers to reject it?
This is the predictable outcome of programming to a compiler rather than a standard (looking at you, python and Julia).
But they are rewriting in c++. I think it will be more tough to rewrite in c++ than in modern Fortran.
Why F2018 will not save? Except generics you have everything.
I agree with the statement regarding C and C++, it seems that backward compatibility is not a show stopper for them.
When comparing the evolution of C++ to Fortran, the rate at which new features are added is much higher in C++ than in Fortran. The drawback of that is feature creep and a complex language, exactly the opposite of what I love about Fortran.
Maybe I have to rephrase my point of view: I have absolutely no problems with developers who prefer old Fortran. I personally find it horrible, but there are many things that I find horrible but I have absolutely no problem if other people like it (for example German Schlager music). What I want to have is a more forward-directed language development of Fortran and I’m under the impression that his would be easier if one compromises on backward compatibility.
Apparently, writing a Fortran compiler is a difficult task (see my recent posts, ifort is wrong on DO CONCURRENT, gfortran on VOLATILE). It is not the first time that I report such bugs, I guess I have reported 10 compiler bugs in the last 10 years. This indicates the complexity required to write a Fortran compiler is already too high and I understand that vendors are reluctant to add new features. But new features are needed to keep Fortran competitive.
If the complexity is too high to be handled, reduction of complexity is a good solution. @certik already said that the complexity of obsolescent features is rather low, but it is still some complexity that for my purposes can be removed.
The old features are not complex - many of the new ones are. It does no good to delete features, as compilers will be required (by their users) to continue to support them. Furthermore, deleting features from the standard means that you lose words explaining how those features interact with the rest of the standard, leading to implementation divergence.
The main reason C++ grows so fast is that their standards committee is ten times the size of Fortran’s. And, if I may be blunt, the vast majority of the actual development work on Fortran falls on just a handful of members. Others feel free to kibitz, but they don’t write spec/syntax/edits papers. If more of J3 contributed to the actual development of the language, more would get done sooner.
Because even F2018 doesn’t have the tools to compile and run for GPUs as easily as C++, and running on GPUs is the main motivation for rewrites to C++, from what I can tell. So to fix this problem, it seems to me the solution is to improve the tools, rather than delete features from older standards.
Thanks for the insight into the work of J3. From an outside perspective, it is hard to understand how much work is required to propose enhancements to the standard.
I hope that the collection of ideas/proposals via GitHub - j3-fortran/fortran_proposals: Proposals for the Fortran Standard Committee will help to distribute the work load on more shoulders. Besides the long list of (sometimes rather vague) ‘issues’, there are already 8 concrete enhancement proposals. I’m particularly interested in default_optional_arguments, namespace_modules, protected_attribute. Is there anything that can be done for those proposals at the moment? Another topic, that has been extensively discussed are exceptions. For me, catching error stop would be the ideal solution:
program exception
real, dimension(3,3) :: A
A = 0.0
try
A = inv(A)
except(5)
print*, 'inversion failed'
end try
contains
function inv(A)
real, dimension(3,3), intent(in) :: A
real, dimension(3,3) :: inv
if (all(A == 0.)) error stop 5
end function
end program exception
However, having new features in the standard is just the first step. There is also the severe problem that it takes long (from my user perspective too long) until they are available. In addition, the quality of the implementation is often not satisfying. What would be a solution to this problem f reducing complexity by removal of obsolescent features is not a solution?
I would point out that one of the reasons Fortran is attractive is that it is a fundamentally simple language, compared to C++. So we do not want to emulate “growing so fast” as C++.
Quite frankly one issue is that there is not a community agreement on many of the features being put forward. That forces a lot of the people who do not agree with the direction to “kibitz”, as you say.
If I may suggest: you, as the WG5 convenor have a lot of visibility, soft power and community respect to help improve the situation. What you can do is get the community on board with the features that the J3 committee is putting forward. More specifically, for 202Y, I would suggest you start early and try to get community support for features that should go in. If you agree, I can help you. We should start a thread here and start soliciting a “draft” of new features, selected from the J3 incubator GitHub repository (or other places if there are some features not yet proposed there). If there is strong community support and involvement from the start, I can guarantee that more people will help. The effort should start from you, as the convenor. But I am offering my help, if you bless this plan. I am happy to organize the community to start this discussion, under your direction.
You are totally right, I actually still need to report the VOLATILE bug. I just found it yesterday and will report it on Bugzilla. Honestly, I don’t think it should get very high priority.
I’m aware of the issues with finding developers for gfortran. I hope you did not understanding my post as a attack on gfortran, my whole scientific career benefited significantly from having gfortran available. So many thanks to you and the team for the amazing work. Without having concrete figures, I would estimate that I found as many bugs in ifort ans in gfortran. So, despite the difficulties of finding developers, you are on par with a multi billion dollar company. I also tried PGI/nvidia, but due to the lack of support for modern features I was not successful.
I think you’re experience with the BOZ constants is a good example for the attitude of many Fortran developers: Avoid touching their code at any cost. Probably they can’t afford buying new punch cards From my side, many thanks for making gfortran standard conforming.
I honestly don’t understand your question regarding bugzilla reports with patches. Do you need someone for testing? I could try to do that, but I’m a material scientist not a software engineer.
Edit: sed -i 's/REAL\*4/REAL(4)/g' is a 1 min quick fix for REAL*4, I don’t understand what prevents someone from doing that if that would be required to be compatible with a new compiler version. Of course, any serious developer should read Doctor Fortran in "It Takes All KINDs" - Doctor Fortran.
I will be in touch in a few months. My first goal is to get LFortran to compile it. LFortran can actually convert the fixed form to free form already for the things it can parse. Converting to modules would be the next natural step, and so on.
From my side, many thanks for making gfortran standard conforming.