FORTRAN was always dedicated to scientific computing, I don't believe it was ever used for system software, so it is a bit apples-to-oranges.
Early versions of PRIMOS used FORTRAN as a systems programming language, although later versions switched to Prime's proprietary PL/I dialect (PL/P) and Modula 2.
The reason for the somewhat unusual choice of FORTRAN as a systems programming language? Prime's founders were experienced FORTRAN programmers, so it was the natural choice for them, and in 1972 alternatives were far less established (C was only just being invented)
I think since f90, modern fortran still is a language well suited to that domain while removing a lot of the cruft (like requiring each line fit on a punch card, things like that, ugh), although the landscape of computing has changed dramatically since with scientists now being relegated to being a niche of computing as a whole. So fortran in that sense is more like a DSL today rather than one of the major use cases for computers, but by luck and history has a lineage with literally the oldest high level language. This is thus more like a historical accident than being something contingent for me. I think the fact that it is suited to computational science is a result, not a cause of it being for scientists (it was designed for us, we didn't find it and build it up or something like that), and the strict aliasing, well, I feel like that's just a lucky break that it was and thus easily optimizable...that and cray, HP et al did make supercomputers to run codes that scientists liked, and thus their architecture and optimizations worked well with fortran codes, and thus the development of both are clearly a coupled situation here.
Anyway, when it comes to today, modern fortran is still a strong language for computational science, specifically for numerical things like simulation and numerical solution and things like that, so when I say, "it is a DSL for computational science today," that encapsulates my opinion succinctly without having to go into the ramble about history, although history is mostly why it is the case today.
Colossal Cave Adventure (ADVENT) was written in Fortran.
Zork (aka Dungeon) was originally written in an obscure Lisp dialect invented at MIT, MDL; but Bob Supnik at DEC ported it into Fortran, and that version became widely distributed.
I used to work for a university, where the software which determined whether students had met all their degree requirements to graduate (such software is sometimes called a "degree audit tool"), was written in Fortran. Why? Well, it was a manual paper-based process, then one of the academics kindly volunteered to automate it for them. And he was one of the mathematics lecturers, and Fortran was his favourite language, so that's what he did it in. Some years later he retired, and without him the software became increasingly difficult to maintain – the university no doubt had some Fortran programmers in the physics/maths/engineering/etc departments, but the central administration's IT didn't. They ended up replacing it with some commercial off-the-shelf solution–no idea what that was written in, but almost certainly not Fortran.
All that to say I think Fortran can only claim to be what we call "general purpose" for a very limited window of time in the very early stages of computing.
In the early 1970s, almost every minicomputer had a Fortran compiler. Lisp was much rarer. Pascal had only just been invented and C was only just being invented. If you wanted your software to be as widely portable as possible, your choices were Fortran or Cobol, and no wonder why many preferred the former. (Especially if we are talking about software in academic/research environments, where Fortran was far more common than Cobol.)
This has little to do with Fortran and Lisp's respective years of introduction (1957 vs 1958), but rather how far they'd managed to spread in their first 15 years (almost everywhere for Fortran versus only to a narrow subset of academic research institutions for Lisp.)
Two other usage patterns I can think of are large strings processing (think bioinformatics and genetics), and things with neural networks (which to be fair would be a natural fit for Fortran, if the libraries were not mainly developed in C++ and accessed from Python). Still, on the HPC facilities I use, number crunching in large arrays dominates used CPU time, and I would say about half of them are in Fortran.
It’s a shame I never really was in a situation to use it in a real program (also, you had to use PGI, which I have always found sub par), but I have tinkered with it over the years and it is very pleasant to use.
Add MPI to the mix, and you can distribute that work to multiple machines. Potentially to thousands of them.
MPI over InfiniBand also can do some computations on the fly (in the HBAs and switches), so it makes it even fasterer (sic).
> This makes Fortran a one trick pony. It does parallel multi-dimensional data very well, but that’s really where it ends.
That one weird trick is a very strategic and cross-cutting one so almost every scientist can benefit from using FORTRAN. So, having one trick is not a bad thing here.
My understanding is that coarrays are a modern replacement for MPI and that coarrays abstract the notion of "machines", they bundle that under "multiple CPUs". I'm not very fluent in either of those, only know as much as the "Modern Fortran" book explains but from the examples I have seen, coarrays can do anything MPI can and they're simpler to work with.
> So, having one trick is not a bad thing here.
Definitely not. Personally, I would imagine myself using it if integration with other technologies over the network was available out of the box.
MPI and InfiniBand are irreplaceable technologies for HPC clusters as of today, both in terms of speed and latency. Lastly IB is not a connectivity layer. It's a HBA which carries information from memory space of one application to another. So it's properly "Magick" in terms of programming and research.
Well, yes and no. Co-arrays are a higher level abstraction, belonging to the category of Partitioned Global Address Space (PGAS).
Depending on the implementation, co-arrays might very well be implemented on top of a MPI library (as there has been a huge amount of work making MPI fast over all kinds of fancy interconnect fabrics).
The author of the book is very active on github: https://github.com/milancurcic.
The language is verbose but pleasant to work with. The latest 2008 version is really nice to look at. My assumption is that working with Fortran 77 and earlier isn’t going to be do nice. With modern Fortran, it’s possible to write generic code, operators can be overridden, new operators can be defined, derived types support inheritance. The language supports pure functions and subroutines verified by the compiler. Programs compile to native binaries.
On the other hand, numbers overflow and there’s no support for any networking without c interop, no byte arrays.
The language shines for multi-dimensional data. For example, multiply every array element by two: [10, 20, 45, 65] * 2. Or, multiply one array over another: [10, 30, 46, 32] * [100, 134, 32, 87]. Up to 15 dimensions are supported. Parallel computing: Fortran coarrays are a relatively simple mechanism to distribute work across CPUs, pin work to selected CPUs, and synchronize the computation across CPUs. Potentially thousands of them.
This makes Fortran a one trick pony. It does parallel multi-dimensional data very well, but that’s really where it ends.
A couple of notes on the ecosystem. The community has done a tremendous job at making Fortran easy. FPM is a package manager designed after cargo. It is really easy to import packages from remote locations, for example git branches. There are some really high quality packages out there, but the ecosystem is difficult to explore because there are no package catalogs. FPM website tries to change that. Editor support is awesome. There are extensions for many editors, language servers exist so code hints and syntax checking also works.
Would I choose Fortran for a new product today? If it had byte arrays, sockets and TLS available natively, maybe.