If you’re ranking lower than Assembler and Perl, it’s reasonable to say that you’re on the way out by a long way.
As said, if the OP was looking to get a sense for whether Fortran is in actual, regular use and can be expected to continue along that path, this thread would be misleading.
Again, I am not denying that there might not be some legacy usage still going on in pockets on the East Coast, in finance, military, and science (though, all science calculation that I have heard of have been using R or Python). Nor would I deny that there is fresh and interesting development in the Fortran world. But there’s also fresh and interesting development in the Perl 6 world. That doesn’t tell you what the status of the language is, it just tells you that die-hard communities exist for everything.
If you have some study like the two above to contradict the sentiment, then feel free to post it.
In my experience and in accordance with actual data, C/C++ had already taken over Fortran for the purposes described by the time I started coding, and Python, R, and Java have supplanted those. Perhaps Fortran was dominant before I got into the business, I don’t know. But I know of anything to suggest that it’s not on the way completely out the door and if you believe otherwise, unless you’re near retirement age, I would say that you would do better to learn some R than maintain that dream.
You raise a legitimate good question as to how extensive Fortran use is among scientists and engineers, but it is hard to tell from a generic poll of uncertain methodology. Also, how do you want to count situations like the fact that C and R and Matlab (which you admit are popular) under the hood interface with BLAS, which is written in Fortran, so that the absolute critical number-crunching component is 100% a “Fortran library”? As a coincidental anecdote, a couple of weeks ago I was involved with a project that used an optimization library written mostly in C++ but a substantial part of the guts of which used, sure enough, Fortran.
Actually writing lines of code in Fortran is not all “legacy usage”, either. Several examples have been mentioned in this thread. Here is another, the “Cellular Automata Library for Supercomputers” (aka “Cellular Grains Package”). Development began in 2013. (Does Bristol count as West Coast or very, very East Coast?) Here is one scientist’s take that certain features of Fortran make code easier to write.
In conclusion, if you count the mere use of a Fortran library, they seem to be rather ubiquitous. If you strictly count only projects where someone is writing at least part of it in Fortran, for instance a special-purpose solver, then the number is clearly down, maybe even much less than C/C++, but demonstrably more than “bupkis”. This link from several years ago describes an, admittedly not representative or statistically significant by any means, survey of eleven Fortran users at a supercomputing conference who seemed quite happy with recent developments. That in itself may tell us bupkis, but it does suggest collecting more apropos information from the target audience than simply spitting out a percentage value of Fortran popularity based on keyword searches of Github and Stack Overflow.
The problem, I think, is that there’s a lot of “science calculation” that you haven’t heard of.
Scientific computing is a weird little niche where, for many operations, FORTRAN happens to be the sharpest knife in the drawer. I’ve written iterative solvers in Python, and it was lovely for that, but it was only for proof-of-concept purposes. Commercial simulation codes compete on solving efficiency, and within our niche, FORTRAN is pretty efficient.
FORTRAN is actively used to write obscure software that solves non-obscure problems:
Did you check the weather today? That forecast probably relied on simulations built using FORTRAN.
Have you survived a car accident? Much of the software used to simulate collisions and design crumple zones is written in FORTRAN. (e.g., LS-DYNA)
Have you flown on an airplane? The wings stay on and fuel is saved due to optimization enabled by software written in FORTRAN. (e.g., NASTRAN)
Got electricity? Nuclear reactors are designed using simulation tools—you guessed it!—written in FORTRAN. (e.g., ANSYS)
…and so on. I’d be shocked if FORTRAN staged any kind of comeback, but the rumors of its demise have been exaggerated.
I loved PL/I but never used it professionally. The only textbook I kept from university is PL/I Structured Programming by Joan K. Hughes. I learned a bit of ADA while working at Boeing but never had to use it since I was on the business systems side.
I started university in 1980 and CS 101 was doing Fortran on punched cards. Never used it commercially either. I’d say the first 10 years of my career was COBOL and the last 25 on C, C++ and Java. I’m currently working on security software where the heavy lifting of the crypto libraries is in C with a smattering of assembler in key places.
When I worked for my state, we used a bridge design program written in FORTRAN by a brilliant state engineer. I’ve seen the coding. Thousands and thousands of lines of code. To think this could be replicated in excel is totally unrealistic. Many years after the FORTRAN savant retired, we hired a university to document it and upgrade it. The university has a lot of computer science expertise, and they told us that the most efficient language for doing that sort of thing was indeed FORTRAN. So they indeed in the 2010s wrote the upgrade in FORTRAN.
Going to college in the 1970s, we learned FORTRAN (and used punch cards, no less). They may not do so today but the language is much more alive than Latin.
I worked for an engineering company in the late 80s, and they had one particular huge old FORTRAN program that was painful to work on. Real ‘spaghetti code’, modified many times, with GOTO statements all over the place, and no comments. Just to figure out what it was doing was a major task.
Fortran was a language purpose-designed for engineers and physical scientists to use, which is why it is so widely disdained by computer scientists. From its limited length variable names and all of the formatting heritage from punchcard days to the inclusion of GOTO statements it is often a lot easier to hack together code rather than organize it in an algorithmically clear or efficient fashion. The spiritual successors to Fortran—data manipulation environments like Matlab or Mathematica, and scripting languages like Python and Julia—make it far easier to write good code efficienctly, and while they don’t perform at the same speed as Fortran, given the capability of modern computer memory and processing throughput, they’re adequte for most of the higher level programming applications that were formerly in the niche of Fortran. But replacing legacy applications that are widely used is challenging. In theory you could write a new version of NASTRAN in C or Cython and get good enough performance, but the core NASTRAN (and ANSYS, and Abaqus) code has been so extensively benchmarked, and is relied upon for providing valid results, than it would be an expensive and challenging undertaking to rewrite the code from the ground up with high confidence of getting the same result with the only benefit of getting away from Fortran. In fact, people have tried to write new finite element solvers in different languages and while the essentials of FEA methodology don’t change, the implementations have been vastly inferior in performance or reliability, hence why these codes are still in regular use despite their age.
We have a code written in Fortran to produce 2D materials properties for fiber-wound composite pressure vessels with skirt extensions that has been in use since the ‘Seventies. A few years ago we took a look at what it would take to rewrite the code in a modern language like Python/NumPy to automatically develop three dimensional properties. (The application is complex but not all that numerically intensive, and since it is essentially just a bunch of coordinate transforms and rules for handling winding transitions NumPy is ideal.) However, after doing a code analysis we realized that not only is the code poorly organized (clearly the product of different programmers or teams over the three decades of development) we don’t actually know what some of the code is even doing and how to replicate it in a different language because of some “black box” transformations that were built into it by some nameless and likely now diseased composite modeling genius. In theory, it would be possible to just write new code and reverse engineer the black box functionality until we could benchmark it against results from the original code; in practice, it was easier to figure out a bunch of workarounds to keep using the code rather than putting the several tens of thousands of person-effort estimated to write and debug a new code. The same is likely true for other applications built on Fortran that are still in regular use.
This is how I read “a good Fortran programmer can write Fortran in any language” – they really mean “someone who is used to writing unstructured spaghetti code can write unstructured spaghetti code in any language”. Fortran is particularly prone to such problems, mostly because its user base is overweighted with physical scientists, whose primary focus is not the programming.
There are also a lot of scientists who deny global warming. At the same time, there are a majority of scientists who endorse global warming and that percentile is growing.
I am not denying that there is not a large legacy codebase (though, I don’t know how large it actually might be) nor am I denying that there aren’t a significant number of people and organizations using Fortran.
But, as Bill Gates (is rumored to have) once said, “640K is more memory than anyone will ever need.” By one standard a number can be a lot. By yet another, it’s tiny. 640 * 1024 is a pretty big number, and that’s not even getting into the size of your bit arrays. Yet, still, this website could not be rendered on a computer with that much RAM.
If your hope was that you would prove something favorable to the popularity of Fortran, all you have accomplished is to prove that my hedge was unnecessary. It appears to be dead everywhere. There isn’t even enough data to split it by subregion.
You continue with the premise that gross popularity is the only metric of whether a language is “living” or “dead” regardless of application. As has been explained many times now, Fortran is a compiled programming language for high performance numerical computing; it was specifically designed for use by engineers back in an era where data structures consisted of basic subroutines and DO/WHILE loops, and there were no desktop computers or World Wide Web. It was never intended to be a language for general purpose computing, and its “market share” has always been comparatively tiny since personal computers became available because it is ill suited to making complex user interfaces, running relational databases, or any kind of “Internet-facing” applications.
It is true that the popularity of Fortran even in engineering and science has fallen, which is largely because you can now buy commercial applications to do statistical analysis, run simulations, and do other numerically-intensive applications with a minimum if any programming (although as illustrated, many of these run on core code written in Fortran). And if data handling and structured manipulation is required, environments like Matlab or Python/NumPy/SciPy allow you to do so without the overhead of a compiler, so Fortran has been relegated to applications where “bare metal” performance is required, e.g. high performance data manipulation such as purpose-specific applications that there are no commercially available applications suitable. In this arena, it is still a useful langauge in active development.
Java was designed from the ground up as a compile-just-in-time language to develop platform-independent applications with Web functionality. It and the JVM that Java bytecode runs upon were never designed for high performance but instead to be sufficiently abstracted that a Java program could be run on any hardware that could host the JVM. Although intended as a general purpose language to replace popular languages like C/C++, it has mostly become a Web interface and application language, so it has actually “failed” in the original intent, but as Web application programming is by far the most popular application of computing it sees wide usage. It is not, however, useful for high performance computing.
This raw popularity comparison is like saying that Ferrari must be dead as a car manufacturer because Toyota makes so many more cars irrespective of which markets each manufacturer is focused upon. The former isn’t trying to put a mid-sized sedan in every suburban garage because that isn’t their niche, and if you are defining that as the metric for success they will fail by definition regardless of how profitable the company is.
Some might read this and get the wrong impression.
Java never made any significant inroads into Web programming - meaning browser stuff, which has almost always been dominated by Javascript. But Java did become the new COBOL for business apps, meaning the back end processing that a Web site (or traditional client) might use for processing the bulk of the functional processing (non-UI).
Subroutines and do loops are not data structures. About the only data structure in Fortran is the array, at least in the Fortran I learned.
Maybe tiny now, but not back in the day when everyone not in business knew Fortran. If it lost market share it is because Fortran is a special purpose language of limited application, like LISP and Snobol. If you went to a library back when I was in high school, you’d find Fortran books dominating.
A few years back we had to engage some academic-type people to develop algorithms. They delivered it in FORTRAN and basically said if you need it ported to something else, figure it out yourself. So I get the sense it’s in use for a lot of pure academic work.
Nobody asked, but I’m really liking Elixir a lot these days and you should give it a try.
Kind of an edge case: Fortran supports complex numbers natively now. In other languages, they’d be implemented as a data structure. And of course internally, they’d be implemented as a pair of floats.
That counts. The last time I had to worry about Fortran was May 1969. So I’m a bit rusty.
Actually I might have written some simple Fortran programs for Numerical Analysis, but it is cloudy.