It is not at all “funny” at developers make inadvertent mistakes and they need remedial “training” that thou shalt ensure implicit none in every program unit and also every interface body construct, thou shalt not define a local object along with its declaration using an assignment. With such “training”, the reaction of these developers is “you lost me absolutely at hello itself”, the complete opposite of Kenny Chesney’s “you had me at hello”.
That is really bad for Fortran.
To keep insisting no, these two features of implicit mapping and implied save must simply remain in the standard for backward compatibility is simply hurting Fortran, when there is no practical risk whatsoever particularly when the “old codes” are beset with nonstandard extensions and the compilers will support nonstandard aspects ad infinitum, when so much of other bad features that are actually used in “old codes”, more so than implicit mapping and implied save have already been deleted
I don’t think that is completely correct. They way I interpret it is that there will always be achieve a certain outcome that was previously possible, but it might not be the same way. For example, in Rust 2018 you could do
panic!(127);
but in Rust 2021 you have to change that to
panic_any!(123);
You can achieve the same thing, but you have to migrate when using later editions.
I agree with you here. My point is that if I recommend for example Rust over Fortran I think we’d be more likely to spend time reasoning about how to design good software instead of avoiding the Fortran pitfalls. I think C++ suffers from the same issues for that matter, maybe to an even larger extent. I don’t know C++ that well though. Maybe if I keep punishing myself with obscure compiler errors from complex templates I’d eventually see the light. Somehow I doubt it…
Fortran - whether we like it or not - is an ancient language like C, and like it, it carries over some features from the past that require a bit of expertise. Are they so hard to learn, or difficult to understand? I don’t think so.
Talking for myself, I can say I totally hate C’s continuous pointer referencing and dereferencing ambiguity, I keep doing it wrong all the time (as of 2022, intent(out) dummy arguments are not possible in C, really?!?). So, the alternatives are not necessarily that better.
Modern Fortran also got several the new features that ensure “safe”, “user-friendly” codes can be developed a la C++ (generics are missing, I know). How awesome is that? Blazingly fast codes that are also well-written. But there won’t be any future if all efforts on Fortran are left to the good will of a few people!
To fix it: help us with LFortran, it does what people are asking in this thread: it keeps old codes running via various opt-in compiler options (we implemented many deleted features and will implement whatever makes sense), and it does not have implicit typing by default. Problem solved.
People switch between programming languages without training all the time! Are they perfect when they’re starting out, no. but they can learn on the go pretty quickly.
Of course people can learn! And they do all the time. Training is a way to learn. Self-learning is another way, but this requires to find the appropriate resources, which is not as simple as it seems. In any case there is a learning curve, and while you are learning you cannot pretend being as skilled as anyone else.
A common misconception is that learning a language is just learning the syntax of the language. It is not. Learning a syntax is just the entry point to write poor code, nothing more. When I see a CV with a long list of “known” programming languages, I am always wondering how many of them are really mastered by the applicant. Generally not many, because really mastering a langage takes time… Sure, someone who is a software engineer has chances to master more languages, because this is the core of his work. But when Fortran comes on the table we are often talking about people who are not software engineers, and the core of their work is not necessarily to learn many languages.
I used the phrase “remedial training” upthread in connection with the detrimental features in Fortran of implicit mapping and implied SAVE: a better term perhaps would have been a big red flag or some such.
Anyone seeking to use modern Fortran in the 2030s and beyond should NOT need to see such red flags or need “training” to avoid these two features. Hoping to simply “win” a “debate” on a thread like these in year 2022, when no practitioner can be seen to actually want to employ implicit mapping and implied save in modern Fortran production codes, doesn’t do Fortran any good.
There is a strong need to flip the “resistance is futile” script and push to get these two harmful features thrown out at least from the language standard.
Easy of use and discoverability of the language are very important for adoption. These are the reasons behind the success of many modern (and not so modern) programming languages.
Lots of people who would write fortran are not computer scientists.
It is of course difficult to predict what will happen or would have happened, for both of us.
But, fact is: Fortran is successfully attacked by at least C++ and Julia. Fact is also that backward compatibility was a major goal during the evolution of the standard. IMHO it makes sense to think about things that can be done differently and I don’t see the benefit of backward incompatible changes if everything one need to do is to set-std=f77to compile old code.
To fix it: help us with LFortran, it does what people are asking in this thread: it keeps old codes running via various opt-in compiler options (we implemented many deleted features and will implement whatever makes sense), and it does not have implicit typing by default. Problem solved.
So you suggest that LFortran has it’s own standard. I conceptually don’t like this, but in fact I do this already with compiler options such as -fimplicit-none.
You suggested upstream that the Fortran standard should require a --implicit-none option. There a few reasons why that won’t happen, but for the sake of argument: How is a user, who cannot be bothered to learn the language by referring to available documentation, going to find this option?
You only specify it once, not everywhere;
It would be enabled by default on build systems, on modern languages build systems are a first class citizen and the default way to develop new software. Open a go, rust, elixir or whatever tutorial, on the first page it will talk about how to create a new project and how to edit options on go.mod or the likes. Fortran will be the same, anyone learning Fortran in the future will learn to either call the REPL or fpm new.
Well, with this answer you have just ignored my point. BLAS/LAPACK (and other libraries of course) could have had modern interfaces from 25 years ago. Backward compatibilty was NO obstacle to this.
These are indeed facts. But correlation and causality are two different animals.
I fully agree, nothing forces developers to update their code. But gamification works: People show proudly on GitHub how much of their code is covered by unit tests. Maybe people would be proud of supporting the newest Fortran standard. Even if not: Everyone starting a new project could make a conscious decision which version of the language they choose: The older version, which potentially can be compiled by more compilers but has some questionable features or the new version with less pitfalls.
The way to do it is via default compiler “style hints” (that you can of course turn off if you don’t like them, or have older code that does not conform to them), LFortran already does it for some older features:
style suggestion: Use '>' instead of '.gt.'
--> /Users/ondrej/repos/lfortran/lfortran/integration_tests/goto_02.f90:10:12
|
10 | if (A.GT.2) go to 95
| ^^^^ help: write this as '>'
Good point, I agree from the technical point of view. Still, I think it makes a difference whether your tools explicitly say: “This is deprecated and should not be used” vs. “You never need to change anything”. Rust has this attitude: Safe by default, but with the possibility to opt out.
Surgeons work under optimized and standardized working conditions. The same holds for other safety-critical jobs, e.g. in aviation: If it turns out that a specific procedure is error-prone, a better alternative will be established. The engineering discipline is called “human factors” or “ergonomics”.