If your code is performance critical, it absolutely matters. Most Fortran code is FORTRAN 77, and 2-20x slower than it could be because it was written for processors without vectorization, out of order execution, modern branch predictors, or any of the other hardware advances of the past 30 years. Modern compilers can mitigate this slightly, but the algorithms that old FORTRAN code use are fundamentally inefficient on modern hardware.
Just curious, how do you know that? I would have thought many establishments would have moved on by now. That said, I've a few of my personal programs that still run on IV - no need to change them as they still work fine (but then they're not running under the auspices of some institution where updating has relevance).
I suppose a more relevant question would be what is the breakdown type of institution still using 77 - educational, research, government, commercial etc. (I know airline bookings and traffic systems used a lot of 77 until recently). I note from another poster CERN is using 95.
I'd reckon legacy systems would be more likely to be found in govt. and commercial and updated more likely in research. (I'd expect there'd be a large disparity between the different types of institutions.)
I haven't done a survey, but from what I've seen, most establishments have moved on. They moved on to C++, python, and julia. Fortran is still fast, but it no longer is unambiguously the fastest, so you need a really specific reason to write code in a less expressive language. (There's a reason the Fortran people are writing their standard library in Python)
If you have not done a survey, then please do not make generic claims in a public forum about a whole ecosystem based on your limited personal observations. I understand you like Julia very much and that you are possibly paid by JuliaComputing to bash other languages in online forums, specifically Fortran here, but please keep your discussions factual.
For a non-exhaustive survey (an exhaustive one would be very difficult because there's a lot of software, and methodology is complicated):
100% of Fortran in scipy is 77 https://github.com/scipy/scipy/search?l=fortran&p=1
ARPACK, ATLAS, LAPACK, ODEPACK, SLATEC, UMFPACK are all notable Fortran libraries that are still fortran77.
A search of github suggest that by repository, there are roughly, 150 f77, 450 f90, 180 f95, and less than 230 for fortran 2003, 2008 and 2018 combined (fortran 2018 is especially dire there are only 6 repos with over 10 stars). however, it's worth noting that github is a site is biased towards newer versions since it only became a relatively dominant platform in the past 10 years or so.
All in all, I think my initial statement is probably wrong by 1 version. The majority of Fortran appears to be f90 or older, and only about 1/5th of fortran code was written on a version of the language from this millennium.
While I do work for JuliaComputing, my posts on HackerNews in no way reflect the views of the company. I'm not sure why you think paying software engineers to bash languages would be an efficient use of resources.
The statement "I do work for JuliaComputing" (which I predicted solely based on your writing style, generic to all JuliaComputing payees) fully explains the nature of your comments and arguments.
Regarding your argument: Counting GitHub repositories is the silliest way of gauging a language growth or decline. The C++ language has nearly 7000 C++11 repositories, only 1600 C++14, far fewer C++20 repositories. According to your flawed logic, C++ is now on life support. A thorough knowledge of a topic is essential before commenting on it or criticizing it as an expert in a public forum. Learn about the minor and major standard releases.
Right, thanks. That makes sense, especially julia. Trouble is I keep falling over Fortran in many unexpected places. What I've not thought to do in any rigorous way until now is to ask about the history of these Fortrans.
They might be "controversial", but they still are absolutely necessary. Modern CPUs typically execute around 3 operations per clock cycle. Without OOO and speculative execution, that drops to .3 (roughly). There's a reason no one is making cpus without them for anything even performance adjacent. Also, just because Fortran code was written without knowing about them, doesn't mean they don't still happen, the only difference is that the algorithms are bad.
