A minor point in Fortran’s favor is that since it is a distinctive name and not a regular English word, searching “Fortran” is much less likely to give extraneous results than searching say “C”. (I fear that although the next Fortran standard will allow functions to be declared simple (a subset of pure), searching for info about “Fortran simple function” will not give relevant information.)
Putting together the [Top Programming Languages list of IEEE] has also made one other aspect of programming languages clear to us: Computer languages have terrible names.
Things started out so well with Fortran and Cobol—brief yet euphonious names rooted in descriptors of language’s purpose: formula translator, business language. Sadly, by the late 1960s, the rot had set in. BCPL arrived, its name a brute acronym for Basic Combined Programming Language, four words that conspire to give no information about the nature of the language or its purpose. BCPL begat B. And B begat C. C itself is a staggering accomplishment, a milestone on every timeline of computing. But its name must be considered a stain on its incredible legacy.
For C begat the even greater nominative monstrosity of C++. This made it acceptable to incorporate symbols, a tradition continued with names like C# and F#. But perhaps even worse is the alternate fashion of just using common nouns as names, for example, Rust, Ruby, and Scheme. Some forgiveness can be given for a borrowed name that’s unlikely to cause a semantic collision in normal use, such as Python or Lisp. But there can be none for such abominations as Processing or Go. These are words so often used in computing contexts that not even a regex match pattern written by God could disambiguate all the indexing and search collisions.
Consequently, some of the metrics that compose the TPL require many hours of handwork to clean up the data (hence our strong feelings). Some languages have their signal so swamped by semantic collisions that their popularity is likely being underestimated.