It's definitely not a dead language – a new Fortran front-end has recently been accepted into the LLVM project, joining Clang. So LLVM's only in-tree supported languages (excluding the various IRs) will be C, C++, Objective-C, and Fortran. It had been scheduled for merge into the LLVM monorepo 2 days ago, but has been delayed pending some additional architecture review.
Latin was dead long before it stopped being used in written works. It died when it stopped being spoken and stopped changing. I don't know if Fortran would be considered dead by the "no longer adapting" definition, but that it's still in use isn't proof it's alive.
Fortran actually isn't a static language. It's evolved over time. The last significant revision according to wikipedia is just over a year old. The beauty and horror of it probably depends which era of it you're looking at.
IIRC, most people who use Fortran use it because there are extremely specialized physics libraries (or astronomy, or chemistry, and so on) that were probably written three to four decades ago by an extremely intelligent PhD student who lacks a proper programming background. Which suggests that the biggest source of horror would be that most code you'll come across was written by a non-programmer who is intelligent en…
"Idiomatic" depends on language and domain and era and purpose. Consider the dgemm method in BLAS (double general matrix multiply, powers all sorts of modern code like numpy). It's such a workhorse, used by everything under the sun. But it does one thing. It multiplies two matrices of doubles. You're going to want to optimize the hell out of it and ensure it's correct, then never revisit it. It's been around (in the exact same form as far as I can tell) nearly as long as I've been alive. The right, idiomatic code for that is going to look different from the right, idiomatic code for something at the business logic level that changes every 6 months. It does it a disservice to shit on it like you are.
IIRC, most people who use Fortran use it because there are extremely specialized physics libraries (or astronomy, or chemistry, and so on) that were probably written three to four decades ago by an extremely intelligent PhD student who lacks a proper programming background. Which suggests that the biggest source of horror would be that most code you'll come across was written by a non-programmer who is intelligent en…
"Idiomatic" depends on language and domain and era and purpose. Consider the dgemm method in BLAS (double general matrix multiply, powers all sorts of modern code like numpy). It's such a workhorse, used by everything under the sun. But it does one thing. It multiplies two matrices of doubles. You're going to want to optimize the hell out of it and ensure it's correct, then never revisit it. It's been around (in the…
You're going to want to optimize the hell out of it and ensure it's correct, then never revisit it.
Balderdash. Claptrap. Codswallop. Poppycock. What if you want to revisit it to make it run on parallel processors? Optimize it for a new CUDA architecture or caching scheme? A new instruction set that handles sparse matrices better? Code lives forever, at every level.
It's definitely not a dead language – a new Fortran front-end has recently been accepted into the LLVM project, joining Clang. So LLVM's only in-tree supported languages (excluding the various IRs) will be C, C++, Objective-C, and Fortran. It had been scheduled for merge into the LLVM monorepo 2 days ago, but has been delayed pending some additional architecture review.
Latin was dead long before it stopped being used in written works. It died when it stopped being spoken and stopped changing. I don't know if Fortran would be considered dead by the "no longer adapting" definition, but that it's still in use isn't proof it's alive.
Lots of number crunching code relies on Fortran libraries even today. Install numpy, it will pull in Fortran stuff.
Numpy actually explicitly doesn't need fortran. It will use some fortran lapack libraries for optimizations if they're present, but it doesn't depend on fortran at all. Scipy is a different story. The need for a fortran compiler was a big part of the original rationale for the divide of numpy and scipy when they replaced numeric. Numpy was meant to be the lighweight/core version of things, and scipy was the full-fled…
I guess "Formula Translator" lives up to its name then!
"Idiomatic" depends on language and domain and era and purpose. Consider the dgemm method in BLAS (double general matrix multiply, powers all sorts of modern code like numpy). It's such a workhorse, used by everything under the sun. But it does one thing. It multiplies two matrices of doubles. You're going to want to optimize the hell out of it and ensure it's correct, then never revisit it. It's been around (in the…
You're going to want to optimize the hell out of it and ensure it's correct, then never revisit it. Balderdash. Claptrap. Codswallop. Poppycock. What if you want to revisit it to make it run on parallel processors? Optimize it for a new CUDA architecture or caching scheme? A new instruction set that handles sparse matrices better? Code lives forever, at every level.
For this kind of linear algebra, you're going to have a different routine for a sparse matrix (dcoomm) or a symmetric one (dsymm) or a triangular one (dtrmm) or symmetric banded matrix vector product (dsbmv) or whatever. Hopefully those are separate functions from your dense one (dgemm), which is what I'm talking about. You'll also have a different function for CUDA (which exists in cuBLAS) than for multi-core (in ScaLAPACK? PLASMA?) than for single-CPU (in BLAS), which is what I'm talking about. General matrix multiply in this sense isn't "all the different matrix multiplies." It's a function with a very specific purpose, and yeah you don't really need to revisit it every decade.
I think you meant to say 1. Zero open issues :o 2. Code is stable - no recent fixes :P 3. Not even the mighty spectre and meltdown demanded a fix PS: I am sure this is meant as a parody to make fun of other frameworks.
I did get a patch some time ago which was really well-written. Almost all pull requests to serious Fortran projects (mostly OpenBLAS) get merged in. I wrote about it here: https://medium.com/@mapmeld/fortran-culture-on-github-a257dd...