Those damn surgeons and aviators and safety-critical workers, why can’t they talk to the dusty deck FORTRANners before making all these backwardly incompatible changes, don’t they know they will “kill” everything by going to better alternatives …
don’t they realize all the code err… “knowledge” in old textbooks they would invalidate, all the stuff on netlib err… walls and notice boards and also the other “established resources” err… the lounge room wisdom that will all be outdated as a result …
don’t these surgeons and what-not just know that once you get absolutely attached to something such as god is real unless declared an integer, you should never, ever change … no matter what.
Agreed. Probably you also agree with the statement “the earth revolves around the sun”. Most people would agree that both statements are true but have no connection to the topic of this thread, which is “Backwards compatibility in different programming languages”.
We don’t need another HPC programming language, which is hard to learn and full of pitfalls, like C++. Fortran should try to fill the market gap as an easy to learn and use HPC programming language without any pitfalls.
Fortran is needlessly making some basic aspects rather difficult to comprehend and for every support request posted online with a confused user or with a program that behaved oddly, there are so many conversations which do not take place online and where users and teams and managers get so frustrated and exasperated with Fortran and migrate away.
Additionally, the coders are not stupid: they absolutely realize so many other programming languages and platforms are constantly trying to do more for them and fast, whereas Fortran is always too little, too slow, and other languages and platform want to get better and quickly, much better not only with the ecosystem but also with the language, and more importantly also learn from mistakes and correct them and not remain “prisoners of the past”. Python 2 / 3 is a good case in point.
Consider this very recent thread (dated 10-27-2022) at Intel Fortran forum :
Note the OP is asking in that thread as to why the compiler did not issue an error toward an implicitly typed object but just gave a warning. OP writes, “Wouldn’t it be better to turn it into a compiler error in future releases? Clearly it would avoid many runtime errors, and save tons of time in order to find them (in large code bases), if warnings are disabled.”
My hunch: OP in that Intel Fortran forum did not realize that the SUBMODULE is effectively a separate program unit that has its own implicit mapping characteristic that is different from the parent module. Thus it is standard-conforming and there is no basis for the compiler to do anything, let alone issue a warning.
Note the standard states
"In each scoping unit, there is a mapping, which may be null, between each of the letters A, B, …, Z and a type (and type parameters). An IMPLICIT statement specifies the mapping for the letters in its letter-spec list. IMPLICIT NONE with an implicit-none-spec of TYPE or with no implicit-none-spec-list specifies the null mapping for all the letters. If a mapping is not specified for a letter, the default for a program unit or an interface body is default integer if the letter is I, J, …, or N and default real otherwise".
and that the program unit can be “main program, external subprogram, module, submodule, or block data program unit”
I think a fair number of Fortranners, experienced even, and almost all newcomers will be similarly confused as the OP at the Intel thread. And a note on the “documentation” - the standard, the Modern Fortran Explained book, other references, websites, manuals, etc. are not clear about this. It is very difficult for ordinary practitioners to grasp the subtleties. Moreover, it is all counter-intuitive to them. So they are left to enter implicit none everywhere like minions or suffer. This is just not right.
Most importantly, it is an absolute travesty that the Fortran standard revisions keep on coming out with semantics where the legacy of implicit mapping simply cannot be get rid of. New things come out such as SUBMODULEs and they get infected too, it is an absolute nonsense, shameful.
RTFM is not the right position nor a good option to dictate to practitioners on matters such as type safety, a modern language should simply embrace it as a starting position itself.
And no modern language can continue to impose 1950s line of thinking such as Fortran’s implicit mapping on new features and hope that it will be seen as anything but a joke. IEEE Spectrum survey shows Fortran is, ridiculous decisions and positions start to add up - it’s like trying to fool all the practitioners all the time.
In the 1980s many scientists were learning C for the first time. The common feeling then was that computer scientists had been complainng about fortran for 30 years, and then given the chance to come up with something better, that was the best they could do? At that time, K&R C did not respect parentheses within mathematical expressions, floating point arguments and expressions were promoted to double precision, the result of integer division i/j was not well defined if either i or j were negative, multidimensional arrays could not be defined with variable dimensions, lower and upper bounds of arrays could not be adapted to the problem, and on and on. There were many glaring faults with the language for scientists (the physical kind, not the computer kind).
Regarding the idea of backwards compability, it is not sufficient to simply have a compiler option that compiles old f77 code. What people really do in practice is to take an old f77 code and add a new feature. Say a derived type argument, or an array expression. Now the code doesn’t compiler with the f77 switch, so a different switch is required. But if the new switch, say f2025, does not compile the old parts of the code, or if the proposed default implicit none change is triggered, then the programmer is stuck. He can’t use the old f77 switch, and he can’t use the new f2025 switch. Instead of a 5 minute modification, it now takes a few weeks to rewrite the f77 code in the new f2025 dialect. That kind of option-driven “backward compatibility” is almost useless in practice, or very limiting at best.
So the real goal of backwards compatibility is to allow the programmer to use old codes unchanged, to use old codes with minimal changes, and to modify old codes in a major way to update capabilities usng new features. That is a difficult task, and of course there are some things that can’t be done that way, which is why some old features of the language have been deleted. But it is especially dangerous to redefine old syntax so that it has a new and incompatible meaning.
C++ is quite successful. But would you say it is “easy” to learn and use?
First of all I don’t know if I would call C++ modern lol. But the answer is “sort of”. One of the keys to C++ success was how it was almost a superset of C. You didn’t need to learn a new language, you just needed to call c++ instead of cc and use new constructs as you needed. That’s discoverability.
That said, C++ would probably be a somewhat more pleasant language if it had not been built on top of C, but it would also be less successful.
But with regards to Fortran: Our main “competitors” are C++, Julia and Python (maybe Rust some day). All those languages are strong in regards to easy of use or discoverability.
That’s not to say we aren’t make progress either, fpm is on par with modern package mangers and definitely ahead of C++ and Python (albeit conda is nice).
Maybe we should try to think in terms of abstract and special cases? A package is a special case of a module with implicit none set by default and some other niceties. All scopes under a package inherit its niceties. But I don’t know how I feel about yet another new language construct. I’m progressively more sympathetic of --implict-none on the build system. That’s how everyone will use the language in the future anyways.
“Most scientific software written today is not based in Fortran, and a recent study of programming languages ranks Fortran 38th, with the top-3 programming languages listed as Python, Java, and C [129]. As part of the BALLISTIC effort, we plan to develop a new prototype library in C.”
The “vocal minority” can enlighten the “silent majority” with enough countervailing examples but otherwise the indications are all, as the Dongarra paper above, that Fortran is not the language of choice for much development for even scientific software.
As I have oft mentioned, Fortran faces major challenges. However continued insistence on sticking with harmful semantics such as implicit mapping in the language standard further allows continued use of “archaic” practices and propagates the image as something “ancient”. Not good for Fortran at all.
Yet just a couple of days ago, you insisted that you do not intend to remove implicit mapping from the language, you just wanted to change the default. Has that changed in two days? Now you want to disallow what you consider to be “archaic practices”?
for every support request posted online with a confused user or with a program that behaved oddly, there are so many conversations which do not take place online and where users and teams and managers get so frustrated and exasperated with Fortran and migrate away.
Ironically, this is exactly the situation that changing the long established default typing rules in fortran will create. Some new fortran programmer will download a legacy code, or type in the code by hand from a textbook, or get a routine from a friend by email, it won’t compile correctly, and they will just migrate away, looking for working solutions in some other lesser language. Unless this is done in a backwards compatible way, I think it is a poison pill, it will kill the language.
The proposal to remove implicit mapping primarily changes only one sentence in the language standard: this proposal requests that the standard state the following, “If a mapping is not specified for a letter, the default for a program unit or an interface body shall be NULL, and the default for a BLOCK construct, internal subprogram, or module subprogram is the mapping in the host scoping unit.”
The net effect of the proposal to remove implicit mapping will be that implicit none becomes the default. Codes that include explicit IMPLICIT statements such as those with IMPLICIT INTEGER(I-N), DOUBLE PRECISION(A-H, O-Z) will be unaffected by the proposal.
Less and less people using Fortran is undoubtly a fact, which nobody really wants to contest.
But attributing this to the silent majority of angry “users and teams and managers get so frustrated and exasperated with Fortran” because of implicit mapping or implied save is nothing but fantasy and fallacious arguments.
Implied save prevents thread safety and parallelization.
There are no recommendations to use them in modern code, in fact the advice is constantly to avoid both.
With 2 above, a true unfortunate event for us has been users and teams and managers who have been adversely impacted by thread unsafe behavior due to explicit initialization in a type declaration statement in Fortran in glue code used to integrate a Fortran library with a business critical cloud application. As the Fortran standard states, “Explicit initialization of a variable … implies the SAVE attribute,” For these users and teams and managers, the main issue is the Fortran language standard changes are too little and too slow and with the two points above, it keeps on resisting standardization of what is now “standard” practice in the above couple of relatively simple aspects even a decade or more from now.
The “fantasy and fallacious arguments” are only about retaining these harmful semantics in the language even after the Fortran 202Y standard revision.
Another “fantasy and fallacious argument” is “Some new fortran programmer will download a legacy code, or type in the code by hand from a textbook, or get a routine from a friend by email, it won’t compile correctly, and they will just migrate away, looking for working solutions in some other lesser language”
The evidence is mostly that current language standard already breaks legacy code in more ways than one, a recent example shown here was NASTRAN. But some compilers as nonstandard extensions try to support old codes. The compilers can do so with implicit mapping and implied save as well i.e. as nonstandard extensions if they so choose. The language standard enhancements are not to be held hostage by this.
I just started reading this book, and found quite relevant quote:
Keep your systems the way they are for too long, and you get caught trying to migrate decades of assumptions
Marianne Bellotti
The point being, the Fortran language has been an enabler of just that. The “old codes” that “still work” have gone so long without being touched that it has become practically impossible to update them at all.
The assertion that “all codes must continue to work as-is” cannot possibly be achieved forever. And so delaying the inevitable, that they will eventually stop working, decreases the chances that it will be possible to fix them when that happens.
So, given that reality, what can we do now to make it easier to update those old codes, and thus more likely that they will be updated, so that hopefully they will continue to be written in Fortran?
In my opinion, changing to default implicit none, and that the save attribute for local variables must be explicit, are rather small nudges to update old codes, with quite straight forward migration mechanisms. In fact, I bet there are already a few tools that could make the changes automatically.
So shall we resign those “old codes” to eventual obsolescence, or shall we encourage them to be updated so that they might live on?
This reminds me of an old Vietnam War era quote. “It became necessary to destroy the town to save it.”
While I think that is appropriate for some features, the trivial implicit typing case is not one of them. It is not necessary to destroy backwards compatibility of the language over this minor issue. I think it should either remain as is, or a backwards compatible way to change the default should be proposed.