Fortran in the TIOBE Top 10

21

2 interesting points from these rankings:

  1. They still use FORTRAN! :open_mouth:
  2. FORTRAN is always almost equally popular on SO and GitHub.
1 Like
22

It’s even more interesting than that: They used FORTRAN until 2023, when they finally upgraded to Fortran. But then in 2024 they went back to FORTRAN!

1 Like
23

Looking at the number of GitHub repos used by RedMonk. But they did not use the number of repositories, but the number of PRs.

Javascript: 30M
Java: 16M
Python: 15M
Typescript: 6M
C#: 5M
C++: 4M
PHP: 4M
C: 3M
Ruby: 2M
Go: 1M
Swift: 1M
Rust: 668K
Matlab: 383K
Haskell: 143K
Elixir: 107K
Julia: 71K
Common Lisp: 27K
Fortran: 26K
COBOL: 5K
Chapel: 268

2 Likes
24

https://fortranwiki.org/fortran/show/readline

There is a difference between reading a line of arbitrary length and reading an unknown number of elements from it, but there are multiple examples of reading a line of arbitrary length into a character variable. Here is a link to (one of?) the first.

So a Fortran compiler written in Fortran without a POSIX-like interface standard in Fortran would be challenging. But sticking to numeric and scientific functionality it seems you should be able to write performant variations of the math-oriented intrinsic functions. This would expose limitations in compilers in Fortran-centric functionality, allow for (in my opinion needed) variants useful for performance, accuracy, and debugging and complement other projects like fpm packages and stdlib. I used to have versions of all the trig functions and many others but so far have not located them. Perhaps a seperate project? Units tests would be useful for testing other compilers; could possibly be leveraged by other Fortran compiler projects(?) and for the most part concentrate on strengthing integral Fortran functionality (most intrinsics are basic to the use of Fortran). They are also educational. Seeing a trig function done with a table, various interpolation methods, recursive versions, ones capable of returning relative error, … having actually used such versions of intrinsic functionality I found them enlightening about how to handle some of the dusty corners of floating point arithmetic and other aspects of programming such as performance and efficient use of memory that helped me to create better proprietary routines that had to address similiar issues.

2 Likes
25

For the people interested, this is a meta-programming-ranking site:
https://plrank.com/

Fortran is visible after selecting “Array” languages (instead of “All”). The (not-) link “rankings overview” leads to the list of language ranking sites used.

1 Like
26

It makes more sense since number of repos could include dormant ones that have not seen activity for years. This would be a misleading stat.

1 Like
27

I think even better than PRs would be the number of (unique) commits, since I suspect a lot of Fortran developers just push code in.

2 Likes
28

My point is NOT that Fortran needs to be “better than C++”, or any other language to write a compiler for Fortran in Fortran.

My point is closely related first to “reveal issues with Fortran for scientific applications”:

  • scale up for bigger and bigger: so many scientific applications in several domains of interest to teams I work with, are getting called upon to solve larger problems and take on multiphysics characteristics in collaboration with different and larger teams to solve more fundamentally. Base language of Fortran itself, never mind the ecosystem, is proving more and more inadequate for these tasks. Even something like enums which is so important to avoid “magic numbers” in code is so poor in current standard Fortran (2023), considering how badly the standards committee effed it up.

  • So much of scientific applications is preprocessing and postprocessing massive amounts of data of all types, especially textual and string. Snail’s pace with enhanced Generics and the refusal of Fortran standards committee to standardize a string type, or to provide the building blocks to practitioners to author powerful container “classes” (derived types) by themselves, say in stdlib, really steers many a large scientific team away from Fortran.

These issues and more would be readily revealed if a team were to simply embark upon authoring a Fortran compiler in Fortran itself.

Note LFortran: the most widely used facility from modern C++ toward lowering the instructions is the string class from C++ stdlib.

The bottom-line: this notion of separating out Fortran as a language primarily for number crunching only in scientific domains is nonsensical. Science for long, at least since CERN ditched Fortran circa Fortran 2008 development period, has needed way more than that. And many other domains beyond science need a safe and efficient and a durable language. It’s a failure of imagination the opportunities and needs of computing elsewhere are unnoticed.

Fortran language with just a few more facilities, about 6 to 8, and all of which many other languages introduced a couple of decades ago or more, can place itself on a solid foundation to land where it belongs permanently, the top 5. The improving ecosystem will do the rest.

3 Likes
29

@FortranFan can you name the 6 to 8 features that Fortran should add?

In LFortran internally we have: generics (templates), lists, dictionaries, union, tuple, set, and a symbolic type (like in SymPy or Mathematica). Of these, only generics are exposed in LFortran, the rest is exposed in LPython. After we can compile all codes, we can easily expose the rest too as extensions.

1 Like
30

Apart genericity, which is on its way for F202Y, what I certainly miss the most in Fortran 2023 is some common data structures as above. It’s not a show stopper, but very often I have the feeling that I have to reinvent the wheel when needing a list, a map… And as I wrote in some other topics, we could have something very close to the C++ vectors with just a minor extension of the allocatable arrays (make them resizable).

1 Like
31

@certik
I don’t know if Fortran must be better than C++ to write a compiler. It’s true that writing a compiler is a large project and so reveals the maturity of the language, however I think we mainly want to reveal issues with Fortran for scientific applications. There are still quite a few issues there to fix. So I would focus on that, rather than focusing on improving Fortran for compiler writing.

Would it be possible, useful or desirable to add inlining of other languages, particularly C, to LFortran?

For example:

program test
use iso_c_binding
implicit none

integer(c_int), parameter :: n=100
integer(c_int) :: i,j
real(c_float) :: arr(0:n-1),temp

call random_number(arr(:))

arr(:)=2*(arr(:)-1)

inline_c

for (i = 0; i < n - 1; i++) {
  for (j = 0; j < n - i - 1; j++) {
    if (arr[j] > arr[j + 1]) {
      temp = arr[j];
      arr[j] = arr[j + 1];
      arr[j + 1] = temp;
    }
  }
}

end inline_c

print *,arr

end program

This would merely be syntactic sugar because the compiler would replace the inline_c ... end inline_c part with a call to a C function, but handle all the passing and type checking of variables.

It could be quite useful for coders requiring specific C functionality without having to write and compile separate C code. One could also inline assembly via the C asm statement.

It could also allow LFortran to become its own bootstrapping compiler.

1 Like
32

Coincidentally enough, not later than yesterday I had the same thought as I wanted to have a robust way of using a dictionary-like structure, so instead of saying “let’s re-invent the wheel a 1000th time” I went looking in stdlib but found nothing, then I was pointed to this repo GitHub - LKedward/fhash: fpm package implementing a hash table with support for generic keys and values. which is almost what I was looking for. Indeed I also think that having a robust support for these kind of facilities natively (or at least in stdlib) would be a good thing.

3 Likes
33

There are apparently hash maps in stdlib: Hash maps – Fortran-lang/stdlib . Looks quite complex to use, though.

34

My reading was that the hash maps in stdlib could be used as a building block to enable fast lookup within a would-be dictionary structure.

35

I don’t know, I haven’t really investigated. To me, (hash-) map and dictionary are synonyms in practice.

36

:slight_smile: hkvzjal, @PierU yes, lists, maps (dicts) and similar are so useful in Python and other languages, that we just implemented them. Our list implementation even seems faster than Clang’s std::vector, so is our dictionary faster than std::unordered_map and std::map. Having them as first class entities in the compiler will allow even more optimizations later on, such as various compile time evaluation and simplification.

My first reaction when seeing your example was negative, it looks like some kind of a Frankenstein of languages. I would rather improve Fortran and stay within one language.

That being said, on the technical level we can do that, we have a C frontend, which compiles to ASR, so at least for a subset of C and C++ we can freely mix them internally, ASR doesn’t care which surface language it came from. Regarding conversions: we support that already (ASR<->C, and ASR<->Python/NumPy, etc.). So it can be done.

But as a user, I think I would like to separate those at least into functions. In LPython you don’t need to do any explicit conversions to and from CPython, that all happens automatically, but it is done explicitly, like this:

@pythoncall(module = "bindpy_02_module")
def show_array_dot_product(a: i32[:], b: f64[:]):
    pass

In Fortran this would correspond to:

interface
    subroutine show_array_dot_product(a, b) bind(python)
    integer(c_int), intent(in) :: a(:)
    real(c_double), intent(in) :: b(:)
    end subroutine
end interface

And the compiler takes care of the argument conversion, transforming the Fortran array descriptor to NumPy array descriptor, etc.

2 Likes
37

Actually, I could also say that this is all what I really miss. Not to say of course that there’s nothing else that would be useful if added to the language, but none looks really critical to me…

1 Like
38
  1. Enhanced Generics
  2. Proper enums
  3. Two intrinsic types: string and bit
  4. Ability to declare default kinds of literal constants
  5. Ability to author an inextensible derived type (mark a type as “final” per OO parlance)
  6. Enhanced pointer semantics
  7. PROTECTED components of derived types
  8. Enhanced MODULE standardization that can mitigate the “MOD Hell” with the practice of modern Fortran

Now, some of these are on the Fortran 202Y worklist, but the issue is the official standard revision to be published later - which exact facilities, with what semantics, and when the work gets completed in this revision.

7 Likes
39

I would like to see the following features:

  • namespaces for modules
  • exceptions
  • dictionaries
  • lists

Namespaces would make it so much easier to read the code because one can see always where a function is defined.

Exceptions would be really helpful for writing tests that ensure that invalid input is rejected.

Dictionaries are helpful for many things.

Lists could solve the issues that many people have with string: A list could contain strings of different sizes, which is IMHO the better solution than having a varying string type.

Dictionaries and lists will certainly be challenging for Fortrans rigid type system, but having them as part of the language should allow more flexible and performant solution in comparison to the existing third-party libraries

40

My Santa Claus wishlist, stealing a lot of other’s ideas :

Plus, as you did not bound imagination:

  • Interoperability of C++ class and Fortran class (just like C struct and Fortran types are most of the time interoperable)
1 Like