All these Community efforts have gotta help quite a bit with the use of Fortran even if quantifiable evidence is always hard to come by.
In some domains, the annual survey results by IEEE Spectrum catches more interest and in it, Fortran has been sliding steadily for a while to be effectively irrelevant which is more reflective of reality:
My impression is that IEEE is more reflective of the Electrical Engieering and Computer Science communities where Fortran was apparently never popular. But I have not read their survey criteria.
This is one of their articles where they explain, itâs about as comprehensive as it can get in present times:
@jacobwilliams once LFortran is fully delivered, I think that will help a lot too.
In Stack Overflow Developer Survey 2023
Fortran is at 0.95% and MATLAB at 3.81%.
I donât know if we can rely on google trends. Interest for âFortranâ by region looks very suspicious to me:
Where I work, many people build their entire code base with Matlab. Therefore, they have to buy licences and because they have to, they continue to program with Matlab.
Fortran is quite popular in engineering and computational studies in China and Korea. At least that is the case I have experienced in my area of research. Also, I have seen some relevant Japanese literature; they use Fortran too.
If you choose by City, I got something below, it seems the users are mostly in the US, EU, and East Asia.
I work in JĂŒlich! 
Jane and I process the log files of our web sites and the following table summarises Fortran file access and download for about the last 7 months.
| Algeria | 3 |
|---|---|
| Argentina | 6 |
| Australia | 193 |
| Austria | 6 |
| Bangladesh | 22 |
| Belarus | 5 |
| Brazil | 4 |
| Bulgaria | 4 |
| Canada | 51 |
| Chile | 2 |
| China | 116 |
| Czech_Republic | 8 |
| Denmark | 56 |
| Dominican_Republic | 9 |
| Egypt | 1 |
| Estonia | 2 |
| Europe | 5 |
| Finland | 4 |
| France | 4756 |
| Germany | 227 |
| Hong_Kong | 14 |
| India | 227 |
| Indonesia | 2 |
| Ireland | 376 |
| Israel | 2 |
| Italy | 66 |
| Japan | 204 |
| Korea | 7 |
| Korea_Republic_of | 113 |
| Malaysia | 1 |
| Mexico | 7 |
| Netherlands | 373 |
| New_Zealand | 35 |
| Nigeria | 55 |
| Norway | 9 |
| Oman | 2 |
| Pakistan | 7 |
| Peru | 10 |
| Poland | 58 |
| Romania | 6 |
| Russian_Federation | 2754 |
| Saudi_Arabia | 4 |
| Serbia | 6 |
| Singapore | 18600 |
| Spain | 46 |
| Sweden | 315 |
| Switzerland | 10 |
| Taiwan | 3 |
| Thailand | 1 |
| Tunisia | 1 |
| Turkey | 42 |
| Ukraine | 16 |
| United_Kingdom | 8462 |
| United_States | 15104 |
| Uzbekistan | 18 |
| Vietnam | 10 |
| Zimbabwe | 10 |
| Overall_total | 52456 |
Singapore access is interesting.
One of the things that has always puzzled me about Fortran is why no attempt has been made to keep Fortranâs intrinsic array processing capabilities on a par with Matlab. Fortran should have always been Matlabâs older but still smarter and faster brother. Why are there no intrinsic set utilities like unique, union, intersect, setdiff etc. I wrote my own workalike versions of these to support nearest neighbor type problems with unstructured grids in CFD and FEM codes. However, these are just another example of things I think should be an intrinsic part of the language (more so than a lot of the stuff that pollutes the standard these days) but the Committeeâs (and compiler developers) answer is still âwrite them yourselfâ. If Fortran did match Matlabâs features and with LFortran offering an interactive version of the language, there would be little reason for Matlab to exist.
Germany access are oddly low compared to equivalent european countries like France and UK.
I think he created that issue, since rweed is his GitHub moniker, based on a previous post.
Thank you @cmaapic !
I sorted the column 2 of your table from high to low, here it is,
| Overall_total | 52456 |
|---|---|
| Singapore | 18600 |
| United_States | 15104 |
| United_Kingdom | 8462 |
| France | 4756 |
| Russian_Federation | 2754 |
| Ireland | 376 |
| Netherlands | 373 |
| Sweden | 315 |
| Germany | 227 |
| India | 227 |
| Japan | 204 |
| Australia | 193 |
| China | 116 |
| Korea_Republic_of | 113 |
| Italy | 66 |
| Poland | 58 |
| Denmark | 56 |
| Nigeria | 55 |
| Canada | 51 |
| Spain | 46 |
| Turkey | 42 |
| New_Zealand | 35 |
| Bangladesh | 22 |
| Uzbekistan | 18 |
| Ukraine | 16 |
| Hong_Kong | 14 |
| Peru | 10 |
| Switzerland | 10 |
| Vietnam | 10 |
| Zimbabwe | 10 |
| Dominican_Republic | 9 |
| Norway | 9 |
| Czech_Republic | 8 |
| Korea | 7 |
| Mexico | 7 |
| Pakistan | 7 |
| Argentina | 6 |
| Austria | 6 |
| Romania | 6 |
| Serbia | 6 |
| Belarus | 5 |
| Europe | 5 |
| Brazil | 4 |
| Bulgaria | 4 |
| Finland | 4 |
| Saudi_Arabia | 4 |
| Algeria | 3 |
| Taiwan | 3 |
| Chile | 2 |
| Estonia | 2 |
| Indonesia | 2 |
| Israel | 2 |
| Oman | 2 |
| Egypt | 1 |
| Malaysia | 1 |
| Thailand | 1 |
| Tunisia | 1 |
It would be cool if Fortran added these types of functions into the standard. It would be important for the language intrinsic versions to be performant though, or else you end up with the embarrassing situation of an interpreted scripting language embedded in a huge gui (Matlab) issuing calls to optimized libraries and being faster than the binaries generated from compiled Fortran. At that point it would be just as reasonable to state the opposite: why does Fortran bother with these intrinsic functions that donât even perform as well as Matlab?
In this case I would say Matlab could also be easily replaced with Python using Numpy.
Lacking common data structures like hash sets might make some of these algorithms difficult to implement in native Fortran as fast as whatever implementation is provided by Matlab/Numpy.
All, please, no more regurgitating the same off-topic argument (J3, WG5) over and over again, which is well taken several times but not hundreds of times. If you have something to write here about Fortran being on the TIOBE list, please do so.
This study of the Top 8 Most Demanded Programming Languages in 2023 is less encouraging. The fractions of developer job ads mentioning various languages used for scientific programming are Python 19.64%, C/C++ (an odd term since they are distinct languages) 9.14%, Matlab 0.10%, R 0.10%, Fortran 0.01%, Julia 0.00%.
Of course, Fortran is a useful tool when paired with expertise in some domain of science and engineering, and it is sometimes listed as a qualification for graduate student and post-doc positions.
Moderators would be entirely remiss and abusive of their ability to censor if they remove my post.
Everything I wrote in it is as a matter of fact the truth and nothing in it is targeted toward anyone individually.
There would be no basis for the moderators to remove it, but I will not be surprised if they disappoint me. Nonetheless, I am placing higher expectations on them and anticipating the moderators to have the sense to override the flagging that whoever did on that post.
Each monthly reading includes a brief comment by Paul Jansen, CEO of Tiobe. This time (while updating the numbers about August '23 for entry 86 in this thread), it highlights Juliaâs first appearance among the top 20 in this metric with
«So what makes Julia unique? Why does it deserve this top 20 position? Julia is especially used in the data science and mathmematical computation world. But we already have got top 20 contenders in this field such as Python, R and MATLAB. So why then Julia? Well, Julia is faster than Python, more suitable to write large systems in it than R and less expensive than Matlab. So, speed, scalability and being open source make Julia an attractive alternative.»
These advantages equally apply to Fortran. He continues with
«On the other hand, Julia requires more programming skills than the other 3 languages mentioned, so it is really interesting to see whether it can keep its position between the âbig boysâ.»
