I personally do think Fortran language itself also requires an urgent boost to serve well the scientific and technical computing arenas. And this is in addition to everything needed in its “ecosystem”: standard library, interpreter and other enhancements in tooling, etc.
The notion of Turing-complete may be too abstract and even too basic any longer for any practical utility with modern languages. Nonetheless, one can think of an even more abstract notion of feature-completeness that can be more practical and which can resonate intuitively with those coding-in-anger regularly in scientific and technical domains. This notion is decidedly dependent on the time period, the state-of-art in computing at a given instance in time. On this count, Fortran has perennially fallen short of the needs of practitioners since ANSI FORTRAN publication back in 1978. And the deficit continues to this day.
I had previously noted 6 items in this thread which are crucial for immediate survival of the language as a legitimate contender in the scientific and technical computing space.
However I do believe there is a list of miscellaneous items in the syntactic sugar category that can make coding in Fortran far more safe, straightforward, and appealing and enjoyable, especially for scientists and engineers who should be and want to be domain experts in their respective fields, and not language masters:
-
Why are we still required to include
implicit nonein every scope in Fortran? Particularly inINTERFACE .. END INTERFACEconstructs that has its own scope and which made it into the language much after the legacy with IMPLICIT statements. This is especially pernicious, particularly with any respect to diversity and inclusivity which is all the rage these days with social justice. Because the common refrain is “I don’t mind adding that statement” in all my codes, so nor should you - this is inherently disrespectful. Well, there is a vast group of scientists and engineers who are either unable or unwilling to follow the discipline in terms of this verbosity. And the cost of any indiscipline can be prohibitively expensive, particularly in commercial environments. And continuously excluding the inclinations of those wanting to advance to a modern state where the desire to be explicit with types is the default “value proposition” from language design considerations is forcefully ignored not only belittles any concept of type safety but disrespects the most precious commodity, the time of practitioners. -
There are so many domains now where 100% of the computing is performed using IEEE floating-point arithmetic. Then, why are we still required to go through a long preamble with one’s own KIND module that sets the desired floating-point KINDs for use with IEEE formats. Fortran can do with built-in aliases, say
ieee_fpb32,ieee_fpb64, etc. (or something less verbose) that coders can immediately employ toward floating-point computations with an intuitive grasp and confidence in the types. -
Same applies to other intrinsic types and their kinds, especially
INTEGERandCHARACTERwith `c_char’ kind. -
And of course, a built-in string type. Sure, initial experimentation in a standard-library years after
ISO_VARYING_STRINGis a decent reset, but it is the base language itself that needs this facility to be included intrinsically.
The rate of change with all of these features in standard Fortran is either too slow or zero. Fortran is headed to science museum archives unless things change for the better at a much faster pace.