fortran-wringer-tests VS Fortran-code-on-GitHub

An ISO standard should promote portability across implementations, prevent breaking changes to the language, and coordinate design, prototyping, testing, and description of new features.

Fortran features since F'95 are not terribly portable (https://github.com/klausler/fortran-wringer-tests); the F'23 standard has a needless breaking change; and every revision contains incompletely thought through features jammed in without prototyping ("rank agnostic array indexing"). They won't fix bugs, either -- it is possible to write DO CONCURRENT loops that are completely conformant but cannot be parallelized (and cannot be determined at compilation time).

> OTOH, the existence of an ISO standard with multiple implementations can benefit the portability and longevity of code.

This is true for ISO standards that actually standardize features. Fortran's standard, since F'90, has instead been inventing features, and doing so without prototyping in actual implementations. And without supplying standardized test suites to guide those implementations. The results, in actual practice, have been at best mixed. There are features that are "standard" but not at all portable, due to spotty and divergent implementations, and there are portable features that are not standard. Some features have been in the language for >=20 years without yet appearing in popular compilers.

So yes, standardization (ISO or otherwise) can be a good thing. But it hasn't really been so for Fortran. And I think things are getting worse; F'2023 has changes in it that actually silently change the behavior of existing standard-conforming code, which would have been viewed as an abomination in earlier days.

References: see the LLVM Flang documentation on extensions, non-standard features, &c. in https://github.com/llvm/llvm-project/blob/main/flang/docs/Ex... and a suite of various incompatible feature tests in https://github.com/klausler/fortran-wringer-tests .

If "it" is F'23, then none. GNU Fortran has had the "new" degree-unit trig functions for a while, but no compiler, FOSS or otherwise, has the newly invented features of this revision.

Fortran doesn't prototype features with real implementations (or test suites) before standardizing them, which had led to more than one problem over the years as ambiguities, contradictions, and omissions in the standard aren't discovered until years later when compiler developers eventually try to make sense of them, leading to lots of incomplete and incompatible implementations. I've written demonstrations for many examples and published them at https://github.com/klausler/fortran-wringer-tests/tree/main .

The hints in place ("there is more infrastructure already available outside Fortran, consider using them instead"). Beliavsky's compilation Fortran code on GitHub with its section about neural networks and machine learning still may be worth a visit e.g. how let Fortran reach out for the implementations in other languages.

There is an interesting directories compiled about projects around Fortran, Fortran code on GitHub. Though artificial intelligence does not appear by name, section Neural networks and Machine Learning may provide an entry.

My list of Fortran codes on GitHub has a section Containers and Generic Programming with some of the data structures you mention.

There's modern stuff being written in astro(nomy/physics) (I can attest to some of the codebases listed in https://github.com/Beliavsky/Fortran-code-on-GitHub#astrophy... being modern, at least in terms of development), but I'd say C++ likely does have the upper hand for newer codebases (unless things have changed dramatically last time I looked, algorithms that don't nicely align with nd-arrays are still painful in Fortran).

I've also heard rumours of Julia and even Rust being used (the latter because of the ability to reuse libraries in the browser e.g. for visualisation), but the writers of these codebases (and the Fortran/C/C++/Java) are unusual—Python and R (and for some holdouts, IDL) are what are most people write in (even if those languages call something else).

"QuantEcon:Open source code for economic modeling" https://quantecon.org/ has Python and Julia versions. The Federal Reserve uses Julia in its macroeconomic models: https://frbny-dsge.github.io/DSGE.jl/latest/ . Some economists use Fortran (which is much modernized since FORTRAN 77), and there is a 2018 book Introduction to Computational Economics using Fortran https://www.ce-fortran.com/ . Some Fortran codes in economics, statistics, and time series analysis are listed at https://github.com/Beliavsky/Fortran-code-on-GitHub .

At the "Fortran Code on GitHub" repo https://github.com/Beliavsky/Fortran-code-on-GitHub there are many codes listed in the "Climate and Weather" and "Earth Science" sections.

Fortran 77 and later versions (most recently Fortran 2018) have strings. There is the limitation that the elements of an array of strings must have equal length, so that ["boy","girl"] is invalid but ["boy ","girl"] is. Libraries for manipulating strings in Fortran are listed at https://github.com/Beliavsky/Fortran-code-on-GitHub#strings .