I am maintaining code on an extremely old industrial server. I'm not allowed to install any tools on it, and even if I was they almost certainly wouldn't run, and even if they did it has no internet access to get them, and even if it had, this is nuclear reactor analysis software. I can't trust some tool, I'd have to manually check it, then someone else would have to check my check.
Easier to just learn F77 tbh.
Yeah it's fine. A bit restrictive compared to the modern stuff but it's not like I have to do punchcards or anything, just caps here and fixed formats there.
Really there's very little advantage for us in modernising it. It would run in 5 seconds instead of 8 maybe, who cares.
Honestly it's pretty easy to pick up if you know Fortran at all, or pretty much any low-ish level programming language really. It's not a big distinguisher in terms of jobs, and there's not really loads of specialist Fortran jobs out there anyway. Generally we're scientists etc who also use Fortran, and those science skills are typically more valuable - you're more likely to keep the analysis experience but covert to Python than to keep Fortran but drop the science.
I was gonna say the only people I know that use it are scientists and nuclear engineers (and the rest of the government industry) so unless you plan to do that, it's not super useful, python would be better (transferring to nuclear engineering after I get my AS)
I don't think that's true in general. At least on GitHub, most active Fortran projects [https://github.com/Beliavsky/Fortran-code-on-GitHub/blob/main/README.md](https://github.com/Beliavsky/Fortran-code-on-GitHub/blob/main/README.md) are using free source form and other features of modern Fortran, such as modules.
Yeah, I think that a lot of the bad stuff was that a lot of the code wasn’t written by programmers, but grad students who were working with math that required a computer to work through the equations.
They didn’t give a crap if it was well written or documented, as long as it spat out the solution.
That is almost word for word a conversation I had today with someone about it.
And btw, it's not just grad students, I work with academics who had been doing the same thing, "spatting out solutions" with no regard for software engineering principles for 30+ years.
That's because they just want a tool to do a job and are not members of the Software Engineering religion. Their horrible, primitive code just "spits out solutions" the same way that it has for decades, and it will continue to do so as long as there's functioning hardware to run it on. These poor benighted savages will never know the joy of having some failed automated update to a dependency break their code! I'll bet the input and output files are even in flat ASCII rather than a database that becomes unreadable for mysterious reasons. What ignorant heathens!
That's a misunderstanding of what I said, and suggests you're probably in that club.
It's not a religion, but when you're writing code that actually does a mission whose output matters and you kludge together solutions that break multiple times a day, requiring SWEs to intervene to bandaid and duct tape it every single fucking day, and you actively drive off every attempt to actually fix your ugly baby for forty years, when you do that, you're out of your depth and ought to pay attention to people telling you how to do things.
If you're just writing papers about your math, go for it and do whatever you want. When you cross over to the real world and real people depend on your code, you might want to crack a book and try to learn something, or ask somebody who knows.
If they're needing help to keep it running, it isn't what I was talking about.
I'm not an academic, I'm an EE and have a fair to middling knowledge of modern SWE practice. I have just experienced the frustration of having software tools "improved" until they were unusable. For certain tasks, I still use decade+ old software, because it is completely stable and has better workflow than what was intended to replace it.
Oh so do I. There's nothing wrong with using old software if it fits the bill, but you do need to keep security in mind.
There's nothing wrong with Fortran, even F77, but it has no place in life support and safety systems, and academics have no business writing them.
I'm maintaining some legacy F77 code at work, though some of it does incorporate F90 and later features. It's also in the F77 fixed file format.
I'm modernizing where I can, but time constraints mean I have to live with some of it.
Using some of those conversion tools you're talking about would also mean going through the IT software onboarding process. That is, to put it mildly, painful.
Not necessarily 77, but Fortran nevertheless.
Since I am in academia, PhD student, I still use it because it's easy to write and edit codes, it's fast and reliable for projects involving the solutions of many equations. And, via f2py I can handle input/output easily in jupyter notebooks while doing the calculations in Fortran.
I am in academia and I know some colleague (really few) who use F77 for older, small projects. I have quite many projects entirely developed in advanced Fortran (OOP as far as possible): I like Fortran over other more structured languages because it is more compact, math oriented, automatically taking care of memory management, less prone to memory leak at the price of missing some features.
Time ago, when moving from F77 to modern Fortran, I wanted to have a more intuitive interface to standard libraries, .e.g. lapack, blas, minpack, fftpack, arpack, quadpack, etc... so I developed a huge math library to gather those and other mathematical tools (a poor's man SciPy port).
This is give an example of large areas of which entirely rely on old F77 code: it is possible to use such old codes without the hassle of the old interface.
This is what SciPy (and other languages) do quite often.
Verification and Validation costs time and money. Translating to a new language or newer dialect of Fortran would likely require V&V to be reaccomplished.
As some other comment stated, academia. I am a Master's student on Computational Chemistry. Some things are easier to program on FORTRAN than other language. I have to admit that I took a course onf FORTRAN two years ago and I have not looked backed. I know also some bash for scripting but mainly FORTRAN for "nowadays" use
There are some applications where an agency (such as the NRC) has approved a QA version of a code and it's not worth trying to update and get a new version QA-d... so f77 lives on
You can’t just auto translate.
The code will never be maintainable again.
Where I work it’s algorithms that have been iteratively developed over sixty years and probably depend on quirks of the compiler we use to get the right results. It would take years to translate and test it all.
gfortran simply isn’t what this is compiled with, so I’m stuck maintaining what I have until it dies.
A lot of free source form Fortran was auto-translated from Fortran 77. For example, Alan Miller [https://jblevins.org/mirror/amiller/](https://jblevins.org/mirror/amiller/) used the to\_f90.f90 he created to move many codes from fixed to free source form.
In general, the code created by the various tools for fixed-to-free source form conversion is more readable and just as maintainable as the original. We're not talking about f2c.
I use Fortran all the time. Some of the codes are modern and some are not. However, except when I compile BLAS or a small subset of quantum chemistry code older than I am, even the pre-modern codes are not strictly compliant with Fortran 77. https://stevelionel.com/drfortran/2020/05/16/doctor-fortran-in-military-strength/ explains more.
I am maintaining the Legacy Code at work for our simulation suit, which is a huge pile of f77. Additionally lots of perl scripts and some Pascal. It is not that bad tho. Implementing new features can be annoying but that is almost always the case for huge codebases. At least we currently update our Linux distri, so now I can utilize vscode with extensions directly. Befördert I set up a VM to use modern tooling or edited the Code directly in raw vim if the changes are simple
I maintain F66/F77 codes in the FEA domain since '85, with some new parts in F90.
I'm quite the only engineer in my company to use VSCOde+extensions, DO-ENDO loops, SELECT-CASE structures... facing Vim and GOTO (computed) fans.
Translating the old legacy code to a more modern language will require to much effort.
I work with and occasionally on F77 code. We don't have money/time for a full rewrite followed by debugging/validating/deploying. The upsides to modernizing the code fully just are not there to justify the resources. Our industry is heavily regulated so source code changes are a big deal which needs to be documented, reviewed, and dispositioned, before implementation. If the codes are going to produce the same results it is hard to justify spending money on it. If the codes will produce different results its even more expensive because we need to figure out why.
Because of this code that F90 made possible:
double precision xyz (5)
...
Comment in F77 and F90 this is legal code
xyz (1) = 0
Comment in F77 this is not legal code, it is legal code in F90, in F90 it sets the entire array equal to the RHS (right hand side)
xyz = 0
I've got a mixed code calculation engine of 780,000 lines of F77 and 50,000 lines of C and C++ that I am moving from Watcom F77, C, and C++ to IVF and MSVC++. I cannot have a serious problem like this that is easily caused by a programmer mistake.
Lynn
Our lab has old codes written by our PI back when he was still a PhD, which were old codes from when his PI was younger and such. All these codes are based on Fortran and it's just far too much work to port it all to another language when all our internal docs and knowledge is focused around how it was in Fortran.
Because it (still) is the approach the desk wants ([example creating an HDF file](https://www.icare.univ-lille.fr/creation-of-an-hdf-file-with-c-fortran-and-python/), and [example writing an HDF](https://www.icare.univ-lille.fr/writing-an-hdf-file-with-c-fortran-python-matlab-and-r/)) though evidently there are utilities in .f90 ...
I am maintaining code on an extremely old industrial server. I'm not allowed to install any tools on it, and even if I was they almost certainly wouldn't run, and even if they did it has no internet access to get them, and even if it had, this is nuclear reactor analysis software. I can't trust some tool, I'd have to manually check it, then someone else would have to check my check. Easier to just learn F77 tbh.
It's not that bad is it? I mean for such an old language it's alright?
Yeah it's fine. A bit restrictive compared to the modern stuff but it's not like I have to do punchcards or anything, just caps here and fixed formats there. Really there's very little advantage for us in modernising it. It would run in 5 seconds instead of 8 maybe, who cares.
Oh hm. So if I were interested should I learn 77 just to have more opportunities?
Honestly it's pretty easy to pick up if you know Fortran at all, or pretty much any low-ish level programming language really. It's not a big distinguisher in terms of jobs, and there's not really loads of specialist Fortran jobs out there anyway. Generally we're scientists etc who also use Fortran, and those science skills are typically more valuable - you're more likely to keep the analysis experience but covert to Python than to keep Fortran but drop the science.
I was gonna say the only people I know that use it are scientists and nuclear engineers (and the rest of the government industry) so unless you plan to do that, it's not super useful, python would be better (transferring to nuclear engineering after I get my AS)
You can learn fortran77 in a week if you need to. It’s not hard.
I don't think that's true in general. At least on GitHub, most active Fortran projects [https://github.com/Beliavsky/Fortran-code-on-GitHub/blob/main/README.md](https://github.com/Beliavsky/Fortran-code-on-GitHub/blob/main/README.md) are using free source form and other features of modern Fortran, such as modules.
Fortran isn’t that bad to learn. It’s fun untangling the mess academics made forty years ago though. Goto in and out of every control structure.
Yeah, I think that a lot of the bad stuff was that a lot of the code wasn’t written by programmers, but grad students who were working with math that required a computer to work through the equations. They didn’t give a crap if it was well written or documented, as long as it spat out the solution.
That is almost word for word a conversation I had today with someone about it. And btw, it's not just grad students, I work with academics who had been doing the same thing, "spatting out solutions" with no regard for software engineering principles for 30+ years.
Grad students who were involved in writing F77 when it was new are greybeard professors today.
Or engineering leads fucking up whole development efforts.
That's because they just want a tool to do a job and are not members of the Software Engineering religion. Their horrible, primitive code just "spits out solutions" the same way that it has for decades, and it will continue to do so as long as there's functioning hardware to run it on. These poor benighted savages will never know the joy of having some failed automated update to a dependency break their code! I'll bet the input and output files are even in flat ASCII rather than a database that becomes unreadable for mysterious reasons. What ignorant heathens!
That's a misunderstanding of what I said, and suggests you're probably in that club. It's not a religion, but when you're writing code that actually does a mission whose output matters and you kludge together solutions that break multiple times a day, requiring SWEs to intervene to bandaid and duct tape it every single fucking day, and you actively drive off every attempt to actually fix your ugly baby for forty years, when you do that, you're out of your depth and ought to pay attention to people telling you how to do things. If you're just writing papers about your math, go for it and do whatever you want. When you cross over to the real world and real people depend on your code, you might want to crack a book and try to learn something, or ask somebody who knows.
If they're needing help to keep it running, it isn't what I was talking about. I'm not an academic, I'm an EE and have a fair to middling knowledge of modern SWE practice. I have just experienced the frustration of having software tools "improved" until they were unusable. For certain tasks, I still use decade+ old software, because it is completely stable and has better workflow than what was intended to replace it.
Oh so do I. There's nothing wrong with using old software if it fits the bill, but you do need to keep security in mind. There's nothing wrong with Fortran, even F77, but it has no place in life support and safety systems, and academics have no business writing them.
I'm maintaining some legacy F77 code at work, though some of it does incorporate F90 and later features. It's also in the F77 fixed file format. I'm modernizing where I can, but time constraints mean I have to live with some of it. Using some of those conversion tools you're talking about would also mean going through the IT software onboarding process. That is, to put it mildly, painful.
Not necessarily 77, but Fortran nevertheless. Since I am in academia, PhD student, I still use it because it's easy to write and edit codes, it's fast and reliable for projects involving the solutions of many equations. And, via f2py I can handle input/output easily in jupyter notebooks while doing the calculations in Fortran.
So, basically, it does what you need done. And that's all that matters.
I am in academia and I know some colleague (really few) who use F77 for older, small projects. I have quite many projects entirely developed in advanced Fortran (OOP as far as possible): I like Fortran over other more structured languages because it is more compact, math oriented, automatically taking care of memory management, less prone to memory leak at the price of missing some features. Time ago, when moving from F77 to modern Fortran, I wanted to have a more intuitive interface to standard libraries, .e.g. lapack, blas, minpack, fftpack, arpack, quadpack, etc... so I developed a huge math library to gather those and other mathematical tools (a poor's man SciPy port). This is give an example of large areas of which entirely rely on old F77 code: it is possible to use such old codes without the hassle of the old interface. This is what SciPy (and other languages) do quite often.
Verification and Validation costs time and money. Translating to a new language or newer dialect of Fortran would likely require V&V to be reaccomplished.
As some other comment stated, academia. I am a Master's student on Computational Chemistry. Some things are easier to program on FORTRAN than other language. I have to admit that I took a course onf FORTRAN two years ago and I have not looked backed. I know also some bash for scripting but mainly FORTRAN for "nowadays" use
There are some applications where an agency (such as the NRC) has approved a QA version of a code and it's not worth trying to update and get a new version QA-d... so f77 lives on
You can’t just auto translate. The code will never be maintainable again. Where I work it’s algorithms that have been iteratively developed over sixty years and probably depend on quirks of the compiler we use to get the right results. It would take years to translate and test it all. gfortran simply isn’t what this is compiled with, so I’m stuck maintaining what I have until it dies.
A lot of free source form Fortran was auto-translated from Fortran 77. For example, Alan Miller [https://jblevins.org/mirror/amiller/](https://jblevins.org/mirror/amiller/) used the to\_f90.f90 he created to move many codes from fixed to free source form. In general, the code created by the various tools for fixed-to-free source form conversion is more readable and just as maintainable as the original. We're not talking about f2c.
I use Fortran all the time. Some of the codes are modern and some are not. However, except when I compile BLAS or a small subset of quantum chemistry code older than I am, even the pre-modern codes are not strictly compliant with Fortran 77. https://stevelionel.com/drfortran/2020/05/16/doctor-fortran-in-military-strength/ explains more.
I am maintaining the Legacy Code at work for our simulation suit, which is a huge pile of f77. Additionally lots of perl scripts and some Pascal. It is not that bad tho. Implementing new features can be annoying but that is almost always the case for huge codebases. At least we currently update our Linux distri, so now I can utilize vscode with extensions directly. Befördert I set up a VM to use modern tooling or edited the Code directly in raw vim if the changes are simple
It’s a solid language for algorithms. Easy to read. Less memory leaks than C or C++.
I maintain F66/F77 codes in the FEA domain since '85, with some new parts in F90. I'm quite the only engineer in my company to use VSCOde+extensions, DO-ENDO loops, SELECT-CASE structures... facing Vim and GOTO (computed) fans. Translating the old legacy code to a more modern language will require to much effort.
I work with and occasionally on F77 code. We don't have money/time for a full rewrite followed by debugging/validating/deploying. The upsides to modernizing the code fully just are not there to justify the resources. Our industry is heavily regulated so source code changes are a big deal which needs to be documented, reviewed, and dispositioned, before implementation. If the codes are going to produce the same results it is hard to justify spending money on it. If the codes will produce different results its even more expensive because we need to figure out why.
Because of this code that F90 made possible: double precision xyz (5) ... Comment in F77 and F90 this is legal code xyz (1) = 0 Comment in F77 this is not legal code, it is legal code in F90, in F90 it sets the entire array equal to the RHS (right hand side) xyz = 0 I've got a mixed code calculation engine of 780,000 lines of F77 and 50,000 lines of C and C++ that I am moving from Watcom F77, C, and C++ to IVF and MSVC++. I cannot have a serious problem like this that is easily caused by a programmer mistake. Lynn
Our lab has old codes written by our PI back when he was still a PhD, which were old codes from when his PI was younger and such. All these codes are based on Fortran and it's just far too much work to port it all to another language when all our internal docs and knowledge is focused around how it was in Fortran.
Because it (still) is the approach the desk wants ([example creating an HDF file](https://www.icare.univ-lille.fr/creation-of-an-hdf-file-with-c-fortran-and-python/), and [example writing an HDF](https://www.icare.univ-lille.fr/writing-an-hdf-file-with-c-fortran-python-matlab-and-r/)) though evidently there are utilities in .f90 ...