Backwards compatibility in different programming languages

108

Is this really a fact? I’m skeptical, but if you have a link to some data that would be useful.

I personally do not know of any active programmer who formerly programmed in fortran but has stopped. We have all expanded over time, with shell scripts, Mathematica, Matlab, perl, python, C, and other languages, but all of us that I know first hand are also still active fortran programmers. All the new students and postdocs that I work with are new fortran programmers, but of course that is a preselected subset of the total population. At my age I also know of course many who have retired and stopped programming entirely. So the question as far as numbers go is whether there are more new programmers than there are retiring programmers. Someone, somewhere, must have those numbers and know the answer.

109

I personally know many. Typically it happens when a production code moves from Fortran to C++, just search this Forum if you want some public examples (and I know many more in private). Those people that I know of course still know how to program in Fortran, but since they now use C++ at their day job, they essentially stop using Fortran.

3 Likes
111

I agree 100%.

I’ll buy a beer to anybody from this thread above who submits a PR to LFortran that gets merged. :slight_smile:

1 Like
112

I think that can only be true in a relative sense, i.e. the percentage of all programmers doing it in Fortran keeps on decreasing with time. And that is true for most languages because new ones come up all the time. In terms of absolute numbers, I would be surprised if the number of both active Fortran programmers and actively developed Fortran projects ever decreased.

I don’t think there can be facts about this because it’s impossible to collect the necessary information. All we have are anecdotal accounts from each of us. In my field and in the last 15 years that I’ve been programming Fortran, I know many people that stopped programming Fortran, but I know even more that started programming it and continue doing so. For every abandoned Fortran project, or a project that gets translated to some other language, there may be 10 new ones that get started. But that’s just my field (weather, oceans, and climate). It may be very different in other fields.

1 Like
113

I don’t have direct stats that support that, rather indirect stats that everybody already knows such as the Tiobe Index.

I agree with you : established Fortran programmers don’t stop programming in Fortran… Or more precisely, to follow up on @certik’s remark, don’t voluntary stop programming in Fortran (if you work in a company or on a project that tells you “from now it’s C++ and that’s it”, well you don’t have the choice). However there are obviously less newcomers in Fortran compared to the Fortran programmers who retire.

I’m afraid I have no skill to offer in compiler development :frowning: .

At my modest level, in my company I try promoting Fortran and standing up against the movement which would eventually lead to dropping Fortran for all new developments. It’s not a completely lost cause: even among the young computer scientists we have, some of them still value Fortran. One practical problem (among others) at the moment it that we have been in a massive move towards GPU computing, with the choice of NVidia/Cuda as the unique and standard programming model. This is a no-show for Fortran…

114

To the contrary, both the IEEE Spectrum survey referenced by Dongarra et al. in their paper on LAPACK and ScalaPACK migration away from legacy FORTRAN) and Tiobe Index show the top 5 popular languages such as Python, C++, Java, C, and C# are increasing their dominance in usage and attention in multiple domains.

115

The single thread that is currently active at comp.lang.fortran shows an example of an “active programmer”: https://groups.google.com/g/comp.lang.fortran/c/jtQ7zzx85gQ/m/MXX6rhC7BgAJ

116

+10

I can’t applaud enough this post by @everythingfunctional , this actually comes on top of Brad’s leadership role in the work toward Generics in Fortran 202Y where amongst many advancements in the semantics, a reassuring basis is that everything is essentially explicit with their work in templates in Fortran. It was likely a simple matter for them to pursue such an approach, but that’s a big step forward for Fortran. So a big thank for you that.

117

I wrote most. These surveys are a dime a dozen. They sample but a sliver of the landscape. Here’s another one with quite different results: Stack Overflow Developer Survey 2022.

118

@certik, sorry but I don’ think that is a good idea. Dialogues need level-setting but that is not possible here:

  1. How does an inquiry on a Fortran code-related matter by @everythingfunctional , “So shall we resign those “old codes” to eventual obsolescence, or shall we encourage them to be updated so that they might live on?” get conflated with war and tens and hundreds of thousands people actually dying and unimaginable tragedy? What kind of fearmongering is with bringing war analogies and a town getting destroyed with Fortran?

  2. Consider a couple of lines from code from COLUMBUS, the one worked on by one of the posters you referenced:
    Columbus/source/constraint/constraint.f · master · Columbus / COLUMBUS · GitLab
    Columbus/source/constraint/constraint.f · master · Columbus / COLUMBUS · GitLab
    Columbus/source/constraint/constraint.f · master · Columbus / COLUMBUS · GitLab

All that implicit mapping proposal strives to achieve is for the standard to change to implicit none as the default at the next opportunity, which is quite far out as I have written repeatedly. This has no bearing on “old codes” such as COLUMBUS and almost every other legacy code. So many are nonconforming already, see statements in above such as IMPLICIT REAL*8(A-H, O-Z) and nonblock DO constructs such as do 10 i = 1, natoms 10 atom(i) = i, an already deleted feature in the current standard. There is no practical connection with “old codes” and “backward compatibility” with a future change in the standard. The “old codes” are already broken, as I show again and again with NASTRAN, COLUMBUS, etc. There are many more in my experience, some I can try to share but many other codes I can’t because I won’t be granted the permission to share online even if they are not being used.

  • what is with deliberately failing to understand a basic idiom “Straw that broke the camel’s back” that accurately reflects truly the situation in our actual experience where implicit none and implied SAVE have indeed caused enough problems with type safety and thread safety and became “the last drop” where powers-that-be put up their hands and decided no more Fortran. A video call is not going with anyone who can’t understand the meaning of the last straw / the last drop or would deliberately overlook it or deny other’s experience.

A modern language simply cannot continue insisting on retaining harmful semantics for years on out that no one actually uses anymore and on the basis of “old codes” that are already so broken as shown above.

119

I thought that was one of the major features of the new llvm intel ifx compiler. It directly offloads fortran code onto the gpu.

I must admit that this issue has been frustrating to me over the last 15 years or so. Back in the 1980s when fortran was the most popular numerical computing language, there was a lot of activity related to attached array processing units. The ones I used the most were the FPS processors, but there were several others, and they all supported fortran, either through low-level assembler libraries or more directly by compiling fortran code. These days, gpus serve that same role (having nothing really to do with “graphics”), yet the fortran activity in this area has been slow.

1 Like
120

This is exactly my point of view. If breaking the backward compatibilty was required to add some important new features to the language, then it would be worth considering. But which important feature would be brought by suppressing the default implicit mapping or the implied save at this point? None…

I don’t know… I just know that Nvidia proposes a Cuda Fortran compiler, although non-free. But our computer scientist dep refuse to consider/install/support any alternative to (C++) Cuda. They just say “Write your code for CPU with whatever langage you want and we will port it to GPU” (and it’s also a way for them to make themselves indispensable).

121

Implicit mapping especially, but also implied SAVE - unless taken out completely from the language and deleted - always pose the danger of infecting all future semantic enhancements in the language standard.

  • SUBMODULEs, though about 12 years old is a relatively new feature in the “annals” of Fortran, and it is infected with the issue.

  • Generics, a very important feature for Fortran 202Y, can fall prey to it any time. Currently, thanks to the vision and influence of those leading the effort, the work is avoiding the infection e.g., a specification of “A template construct has no implicit typing” from a proposal that got voted in by the committee last summer. However the danger is constant, things can change any time and it is a long way to go before the final revision gets published when implicit typing might make its way in. This will require constant vigil.

Thus note the pretext of consistency with legacy / existing semantics, etc. can ever threaten future semantics and the harmful effects of old can forever continue.

So no, the point is not about suppressing any new feature, rather there is a real risk of rendering the new features suboptimal, or even malodorous as is the case with SUBMODULEs. This hinders the adoption of modern Fortran, something it has suffered from since the 1990s.

122

Here it is, yet again, advocating the elimination of implicit typing, after saying just yesterday that your only goal was to change the default to implicit none. You will not convince anyone of the merits of your position, or whether or not we should support it, if it changes daily.

1 Like
123

It appears some readers won’t read or can’t read.

Again, for the nth time …

My posted proposal at J3 Fortran site currently is limited to the ISO IEC standard and focuses mainly on one sentence change in the standard which then will effectively remove ‘implicit mapping’ that occurs by default in certain situations and constructs (c.f. the standard for details), meaning implicit none becomes the default. Readers must note explicit use of IMPLICIT statements are in no way affected by this, thus the option for implicit typing remains in the standard. That is, mine is not a proposal to eliminate implicit typing.

What the work on Generics is focusing on is specific new semantics and constructs that will be introduced for templates, etc. and in those situations only to not have implicit typing - this in no way means the implicit typing is being removed entirely in the language. That is, no existing codes will be broken due to this work - there is no aspect of backwards compatibility that applies here.

If anyone has reading comprehension issues, and some do have big problems with this, please ask first before jumping to conclusions.

Also, nothing will change fundamentally as far as I am concerned: implicit mapping and implied save are categorically bad. Fortran would do well to be rid of them. However in the interest of the slow changes desired by the Fortran standard body, I only have followed up with the J3 GitHub Fortran site with a more formal suggestion with one aspect, the implicit mapping one. Since this won’t be considered before Fortran 203X revision which can be a decade plus away from now, I also suggest to other proposers to consider something like SUPERMODULEs that may offer improved namespacing capabilities in Fortran whilst alleviating in some circumstances the problems with implicit mapping, etc. Thus this is just an idea for an interim remedy to possibly include in another larger aspect (improved namespacing).

Should no one in the Community support this and no one change their minds because of my postings, so be it - they can keep typing implicit none everywhere, more power to them.

I will keep on posting about this and strive to make a few Fortranners realize it is quite daft on the part of the standard to necessitate programmers having to place implicit none in so many places in modern code.

1 Like
125

The fact that this proposal is backward compatible with existing code is good. Please do the same thing with your more general default implicit none proposal.

I will keep on posting about this and strive to make a few Fortranners realize it is quite daft on the part of the standard to necessitate programmers having to place implicit none in so many places in modern code.

The fortran standard does not currently necessitate programmers having to place implicit none statements anywhere in modern code. Currently, if a program works with implicit none statements, then those statements can be removed from everywhere they occur and the program will continue to work in exactly the same way. The implicit none declarations are a useful tool during code development. Afterwards, those statements are redundant.

This fact has been stated several times, by me and by other posters, in these threads about this backwards compatibility issue.

126

The issue is not survival, Fortran will always be around used by some users somewhere.

The issue is about becoming a fully modern language that is type safe by default and generally free of dangerous semantics that hurt thread safety, a key aspect of concurrent programming eventually leading toward parallel programming.

The argument is not that, oh just remove implicit mapping and implicit save and Fortran will be “saved”!! No, not at all

Fortran needs multifaceted efforts in many areas to even become competitive with other programming languages and platforms even in the domain of scientific computing.

However all that effort will mostly come to a naught should Fortran continue to ignore certain deleterious semantics that continue to cause real harm such as implicit mapping and implied SAVE.

Fortran language standard is needlessly damaging itself by persisting with implicit mapping and implied save, there is nothing to be gained by retaining them.

To remove these two features by a standard revision during the next decade at least will be prudent for Fortran. It will mitigate the malodor around the creaky tool which is Fortran now, a tool fast getting ignored by so many who are doing scientific computing.

Retain the two features and Fortran is greatly diminishing its chances of getting noticed as a good tool to use by a lot more in the scientific and technical computing domains. This is the point

127

Re: "… those (implicit none) statements can be removed from everywhere … "

  • this is unbelievable! The folks who want to write modern code would like to “hear” (not)
    • First, if you want to avoid the pitfalls due to implicit mapping, you must type in implicit none in every module, submodule, each interface body for external subroutines / functions (e.g., those from other interoperable libraries with a companion C processor), each unit test that will be a Fortran main program,etc.
    • you shall then remove the implicit none statements afterwards when your development is done - after all, your time is not worth nothing, the dusky deck “guardians” of FORTRAN are doing you a big favor by granting you implicit none and letting you even use Fortran. Plus your development shall always be a once and done effort anyway, you make note of that, one time only?
128

@FortranFan, I am struggling with the complaint about implicit save.
What would the following code do in “FortranFan Fortran” ?

real :: x = 1.0

Are you sure you want to remove the initialisation approach that was provided in F90 ?
And if the variable is no longer to have the save attribute, how is this initialisation to be applied ?
Are you effectively suggesting that DATA statements should be removed from Fortran, unless all these variables are also given the save attribute ?

I should also ask do you even use Fortran any more, or is this just a game ?

129

A compile-time diagnostic that a standard-conforming processor shall be required to detect and report in a future revision of the standard. Consider the following:

real, save :: x = 1.0  !<-- ok, conforming
real :: x = 1.0  !<-- NOT ok, compiler shall be required to detect and report the missing SAVE attribute

And I fully agree, this is an incompatible change in that codes which conform now will be deemed nonconforming in a future version of the compiler.

But it is one that I ask the Fortran Community to willingly accept because the implied SAVE aspect behind a statement such as real :: x = 1.0 is rather pernicious.

No, that is not what I am after - see my code snippet above. My intention is to simply require the SAVE attribute in explicit initialization statements and thus eliminate the implied SAVE that way.

What you write is irrelevant. As suggested above, my proposal will be very brief. It will call for the programmer to explicitly declare the SAVE attribute if they employ explicit initialization. Thus variables in standard Fortran will continue to have the option to have the SAVE attribute. And it will be a must if the programmer chooses explicit initialization. That is it.

But the programmers, once they realize what explicit initialization entails, will mostly avoid it and that will be a good thing. On the other hand, I do have other ideas for “default initialization” of local objects in Fortran subprograms ( somewhat like derived components) but that is a discussion for another thread, some other day - but I don’t see any backward compatibility issue with this other idea.

My proposal will involve no changes to DATA, I will leave the DATA statements as they are - unchanged, whatever be their warts. In a subtle manner though, I am decoupling the DATA from explicit initialization with implied SAVE i.e., undoing the damage from the Fortran 90 revision. So Fortran 90 did the following:

   ..
   real :: x
   data x / 1.0 /

is considered to be equivalent to

   real :: x = 1.0

Instead my change will require the equivalent statement to the DATA one to be:

   real, save :: x = 1.0  !<-- must have to declare the explicit SAVE attribute

I do use a lot of technical and simulation codes written in Fortran and other languages in a consulting capacity, do help improve some of them, and also help troubleshoot issues with them.

However a bigger responsibility for me is to decode many of the existing Fortran programs - some I had authored using Fortran 2003 thru’ 2018 - in plain engineering / scientific / mathematical / algorithmic terms, so that those with predominantly IT backgrounds in C++, C#, VB, Python, C, etc. can migrate the codes away from Fortran and write them in other languages as chosen by powers-that-be.

I don’t get to write much code myself any more, mostly I author small, illustrative examples in modern C++, C#, etc. (occasionally modern Fortran) to help other younger engineers with numerical algorithm development and technical code designs.

2 Likes