New User: I need to write some scientific code. What language should I use?
Me: Fortran!
New User: Fortran? I think my grandpa used to write that in the 1950s. People still use that?
Me: Of course, Fortran is a modern programming language!
New User: OK, how do I get started?
Me: Well, first off, you have to type implicit none (type, external, beep, blork) at the top of every file, and then…
New User: Hold up, why do I have to type that exactly?
Me: Well, in the 1950s, computers were…
New User: Maybe I’ll just use Python.
No, it is not “That’s it”. As I show here, in an INTERFACE body, each and every explicit interface needs to define its own IMPLICIT mapping to avoid problems. This is not a modern language position then, it is an abomination.
I find the argument that implicit none is disturbing for beginners rather unconvincing. There are plenty of equally disturbing features in other languages; try explaining to a beginner, why the executable part of his Python script should be prepended with:
Also, of course, Fortran doesn’t require the functions to be in modules at all (another thing that should be required, but isn’t). So, you have to put implicit none inside all the functions. This is another common “gotcha” for beginners when they forget to do that (just peruse Stack Overflow).
I think the difference is that’s how Python is supposed to work. It’s not having to add boilerplate in order to disable a terrible feature in the language that should never be used, but is somehow the default behavior.
Why not make people who want to use the terrible feature have to type something to use it?
Actually compiler flags are not even necessary, an author can achieve “backward compatibility” with a statement
implicit integer(i-n), real(a-h,o-z)
whilst sparing others the trouble.
Anyways, the arguments being made here against removing implicit none in the name of backward compatibility show no higher purpose or vision to elevate the language Fortran for any computing domain, scientific/technical or anything else.
Re: “That does not show anything useful …,” no, that’s incorrect - it does show something useful to those who can get the context from ellipsis. If not, well there is always the backward compatibility and a whole lot of other arguments to fall back on to allow Fortran to suffer.
I wonder how many codes were “broken” when most (maybe all) compilers moved to allocate on assignment as the default instead of having to specify a compiler flag to turn it on. I know I spent at least a day chaseing a segfault that magically appeared when I upgraded compilers that was due to now having to explicity turn allocate on assignment off. I’m also somewhat puzzled by people who treat the standard as sacred scripture. At the end of the day any standard is just a suggestion on what the interface between Fortran and its user’s should look like and what results a user should expect and thats ALL that it is. Having standards in the past didn’t prevent vendors from adding their own extensions to meet customer demand. Eventually, some of those extensions became part of the standard. I have no problem with making explicit typing the default operating mode and listing it as a vendor extension. This is really more a problem with developers and vendors not having the courage to make a change that at most forces people to modify their build system (and only their build system). They apparently didn’t have that problem with allocate on assignment or recursive functions. Full support for prehistoric Fortran will still be there but the onus is now on the Ludites to make a change and not the people who want to move the language into the future.
Having said all that I’m pessimistic that getting rid of IMPLICIT NONE will ever happen. For some reason (probablly monetary), the vendor’s and developers seem to be the most zealous “true believers” in the standard as gospel and like all religioius zealots become intolerant of others who don’t see the world as they do. Hopefully, I’m wrong but for me the only way I see the language moving in the direction I (and I think many others on this forum) would like is to stand up an open source project to simultaneously 1) fork the modern parts of modern Fortran leaving no direct support for the “old” and 2) develop a bullet-proof set of refactoring tools that can automatically convert old code across an entire code base in a few minutes (or seconds). I don’t know anything about the internals of LLVM flang but maybe that would be a starting point for both a modern fortran only compiler and the set of refactoring tools that will be needed to justify forking the language away from Fortrans <=77. While refactoring can be a lot of work if done line by line by hand, it really is not (in the grand scheme of things) that hard to do if you have a set of tools that you can count on to do most of the heavy lifting. Also, if I was a younger man working in the area of compilers and programming tools, I would welcome the challenge to build a compiler in my own vision and associated support tools that would end the backwards compatability debate once and for all. So who wants to be the Guido Van Rossum of modern Fortran.
When using Fortran for a longer time, typing “implicit none” usually is the first thing one does when writing a new execution unit anyway.
Furthermore compilers have options to warn you if you accidentially perform an implicit decalaration of a variable or even prevent you from doing so.
@rwmsu , good points. It makes sense though that Guido Van Rossum remains peerless! Van Rossum created something many have adopted in their practice and who then consider it their lingua franca, the "FORTRAN" for scientific programming also, even if it’s spelled differently and is “funnier” than Fortran with its own diktats starting with the indentation!
To be clear, in my answer I was not advocating for or against implicit none. I was merely stating, the argument we are losing potential Fortran users due to having “boilerplate” such as implicit none is far-fetched. I would say dynamic typing and rich collections of libraries are far more important factors, which make languages such as Python, Julia, and MATLAB attractive for newcomers.
My personal take with this is “Don’t look a gift horse in the mouth”. I am not involved in the Fortran committee, nor do I have the time to join it, hence I try to refrain from criticism. My opinion does lack any higher purpose or vision, but I’d prefer my contributions to libraries and other Fortran endeavors speak for themselves. Polemicizing about the removal of implicit none will not make Fortran popular again, nor will it magically shift the opinion of the committee on this topic. As they say: “The dogs bark, but the caravan goes on.”
It has been stated repeatedly there are multiple reasons behind the proposal to make eliminate implicit mapping, the issue with forcing new users to always include the “boilerplate” of implicit none in relevant program units is but one of those reasons.
Separately, there are so many actual lived experiences where they have legitimately received feedback from other programmers who have indeed discontinued with Fortran for a number of reasons but who have said the first impression with implicit typing was observably negative and which stayed with them all through. On what basis is someone trying to discount such experiences as “far-fetched”.
If one does not advocate a position in a given thread, why resort to calling anyone (such as @jacobwilliams , @FortranFan , etc.) who seeks community support for a longer term directional advancement as “dogs barking”? Even as the suggested change, all within the slow, grinding process of Fortran standard evolution, that can only take effect decades from now and which provides more than ample time for any codebase desirous of “implicit mapping” to do the needful and which is minimal effort to be unimpacted in any way with the change.
Well, the code compiles perfectly without it (in main program, it does have it in the subroutine!). The question has nothing to do with implicit none issue, it is only some besserwisser’s answer, yellying that he won’t help anybody not using it. But he also yells that REAL(8) is bad. I don’t see anybody proposing the removal of REAL(8) from the standard.
I know. I just though it was funny. But I sympathize with the guy not wanting to help debug code that doesn’t have implicit none, since that’s just such a big source of errors. A totally unnecessary source of errors.
Also real(8) is very bad. There are a lot of bad Fortran habits allowed by the compilers and the standard. Look at this StackOverflow page for a few days and you will see them all over and over and over again.
The “dogs bark…” is a proverb. In this context I was using it as a metaphor for “History moves ahead, no matter the criticism it may attract.” and not for the sake of name-calling. My sincere apology if you’ve taken it personally, I did not mean to offend any supporters of removing implicit none. I have a lot of respect for both yours and Jacob’s opinions. As a small proof, you are currently my most liked Discourse member:
and I regularly follow updates on Jacob’s twitter, GitHub and web-page to learn more about Fortran.
I can understand if skilled programmers and industry tech leads, who understand the concept of typing, are appalled by the notion of implicit typing in Fortran, and the need to “declare” out of it. If that’s the case in your actual lived experiences, I will have take your (anonymous) word for it. But for programming beginners, there are so many programming language concepts which are unfamiliar that I find it hard to believe implicit none would be the one concept driving them away. Obviously, I misinterpreted Jacob’s story, the fictional “New User” is not a programming beginner…
This sounds fine! Some people use the flag. Some people modernize their code. Newcomers never know the old bad way existed and it can be moved into the appendix of the Fortran book, rather than being on page 1! What is the problem? This is why I say Fortran needn’t have an upheaval like the Python 2 and 3 transition.
Should we start vehemently adding implicit integer(i-n), real(a-h,o-z) to any legacy code we come across? Should we start a webpage similar to pythonclock.org, offering advice how to accomplish a smooth transition?
I just though it was funny. But I sympathize with the guy not wanting to help debug code that doesn’t have implicit none, since that’s just such a big source of errors. A totally unnecessary source of errors.