It took only 2 prompts to translate my associations to an image (though I am unhappy with the F here). ![]()
Documenting the many pronunciations of Fortran employed by the AI narrator ![]()
- fur-TRAWN
- FOR-tron
- Fortran
- FOR-TRAN
- For-Tron
- for-TRAN
- for-TRON
Oct 2025: 11, 1.7%.
June 2026: 17, 0.95%
First time below 1% since June 2023 it seems.
TIOBE Index - TIOBE
Once it drops out of top 20, then TIOBE will again not be very relevant or accurate, as people have been saying. ![]()
@CRquantum Yeah, that was quite something earlier this morning when adding the current reading (1.22% in April → corresponding to place 13, 1.22% in May → place 11, 0.95% in June → place 17) to the table (entry 86 to this thread) and the ASCII/csv table. While returning my cup to the shelf, I briefly thought if the kurtosis and skewness of this distribution changed over the time (the .csv links to the corresponding snapshots stored on archive.org) which however wasn’t followed through in favour of «other things™».
Fortran is down to 19th place in the Jul 2026 list. Since the silly index is now trending down for Fortran we can go back to defending the language on its merits ![]()
I have spent much time working on transpilers from Python and R to Fortran. If you have code in Python and especially R, because of their dynamic nature, you only know for sure what Python or R code is doing if you run it. A transpiler must play detective guessing the type and rank of variables and function results. If you introduce an inference rule to make more Python or R codes to translate to Fortran code, it may break other codes that transpile. With modern Fortran, not only can your code be orders of magnitude faster than Python or R, you can infer what it does by looking at it. Fortran is less flexible and more verbose than dynamic languages, but LLMs will be writing an increasing share of code anyway. Once you have an algorithm coded in Fortran, C, or C++ code that can be given a C interface, you effectively have the algorithm in every language using its foreign function interface.
Last month of TIOBE being correct!
In August index, Fortran is back to rank #15 with a 0.99% rating. Below 1%, we can expect the ranking to have a great volatility.
What interested me in the editor’s comments is about MATLAB:
In a world where most programming languages are freely available, having to pay for a MATLAB license is becoming an increasingly significant disadvantage.
Indeed, I have used GNU Octave during the Covid, and I am now using Scilab (GNU GPLv2) to work with a colleague. An interesting and rich language and IDE, but interpreted.
Nelson is a similar one that I’ve never encountered anyone using, but looks interesting. Neither Scilab nor Nelson are on the list of languages monitored by TIOBE.
Thanks, I have never heard of Nelson. The first release dates back to 2016.
Scilab was launched in 1982 by the Inria French laboratory (it was named Blaise, from the forename of Pascal I guess). It is now developed by the Dassault Systèmes company, since 2022. They have a Discourse with 372 registered users.
GNU Octave is a great open-source alternative to MATLAB, but I found it to be extremely slow in my testing. I reported in Fortran do concurrent and OpenMP comparing Octave/Matlab code performance. Octave is much slower than Matlab!
I have never used MATLAB, but those tools are generally interpreted languages. And you need to avoid explicit loops when possible and prefer to write you algorithm using their array syntax (it can be 10x to 100x faster than a loop).
They can be interesting for not too big computations, for quick prototyping, interactive manipulations and plotting, etc. They have the advantages and drawbacks of interpreted languages.
But you can generally also call Fortran subroutines.
MATLAB intrinsics tend to be amazingly fast in my experience, faster than any naive or moderately tuned compiled equivalent source code (C/Fortran), primarily because of exceptionally tuned and optimized (parallel) algorithms used internally. It has a fairly stable interface (unlike the Python ecosystem) with quality visualization capabilities. I think these are some of the factors that make it still worth it for its customers over free alternatives. There is a lot more in MATLAB that I see many engineers find unique and unavailable in other environments.
Up four places, to 11th rank this month (which is up one rank as compared to September 2025). Fortran is now one rank below Rust, one rank above Go, and seven ranks above Swift.
@certik: Let’s try to keep it that way, or (better yet) to get back into the top ten … ![]()
TIOBE continues to be the most accurate language ranking!
Latest Tiobe commentary about Julia is below. ChatGPT says it is easier to call Fortran from Julia than from Python, R, Matlab, or Octave.
September Headline: Is Julia going to re-enter the top 20?
In the summer of 2023, Julia entered the top 20 for the first time in its history. This month, it is close to making it back into that exclusive group. Last month, I highlighted the decline of MATLAB, which had been a top-20 language for decades. This month, MATLAB drops another two positions. What I did not mention last month is that Julia is one of the languages that has taken a share of MATLAB’s territory. MATLAB, Julia, Python, and R all have strong roots in numerical computing, scientific computing, modeling, and data processing. Over the years, both Python and R have taken a significant share of MATLAB’s market, but Julia has certainly claimed part of that pie as well.
So, is Julia here to stay? That is a difficult question to answer. So far, Julia remains concentrated in relatively niche domains and has not yet managed to break through as a general-purpose programming language. It is fast, but there are faster languages. It is relatively easy to learn, but so are many alternatives. Julia has a strong and enthusiastic user community, although, somewhat surprisingly, it did not appear in last year’s famous Stack Overflow survey of the most admired programming languages.
I use Julia like my former boss used Mathematica, for sample, quick things that need to be fast. I use the REPL a lot to do quick, back of the envelope calculations. The one big Julia project I tried using because I needed to do something work related was something in the fluid dynamics space, and just setting it up was a bit of a nightmare on my HPC node because of innode limits, $HOME capacity, the package manager etc. There is some magic to just being able to do cmake ../ and load a system MPI, CUDA, etc. that are well handled by sys admin professionals.
They are super enthusiastic. Just like we are.
