This is how you keep using those efficient, numerically-stable subroutines written by a smart guy who retired 20 years ago in your new code. Unlike Python, Fortran has managed to add significant new features without breaking old code.
Unlike Python, Fortran hasn't seen an increase in usage and hasn't brought the joy(?) of programming to thousands of new programmers in the last 10 years. So sticking to Fortran or backwards compatibility blindly doesn't solve all the problems, either.
Maintenance is key. Most people don't stick around for 20 years anymore either. I know I'm going to have an easier time finding a new hire for a Python codebase. And he's going to have a far better chance at understanding said codebase. Code which nobody knows how to maintain will hurt us either with a fiendish bug, or limit out growth. So for me, slowly moving away from legacy stuff is good business value in the long run.
Remember, you can never be sure that Fortran code is 100% bug free. The test of time is as good as any other test, but not perfect.
Fair enough. But having worked with Fortran code that was designed in pen on yellow legal pads, typed in, and run on a suite of standard test problems chosen to expose subtle bugs, I have learned to respect an archaic engineering style of which few people are capable nowadays. Sometimes code is essentially "finished;" you'd be amazed at how rarely it has bugs. It should be changed only with care and for good reasons, not because the programming language changed to conform to some new fad.
(FWIW, I'd probably write most new numerical code in Julia rather than Fortran 20xx, and either call into existing Fortran via FFI, or drive it from the command line with some scripting language.)
> Unlike Python, Fortran hasn't seen an increase in usage and hasn't brought the joy(?) of programming to thousands of new programmers in the last 10 years.
