*blinks*
I haven't wielded Fortran in anger for more than 45 years, but this really smacked me in the face with self-recognition.
Fortran IV was *remarkably* awful.
I mean, it wasn't assembly, sure.
But other than that? Awful.
@weekend_editor @louisepryor A few years ago I modernized a 1979 adventure game from F66 to F2018: https://gitlab.com/apthorpe/Castlequest
It took some effort but I managed to refactor away the 750 or so GOTO statements in the main game loop. It's kind of a pathological case but the code is now in good shape to go another 40 years without maintenance. :)
@weekend_editor @arclight @louisepryor
Fortunately, the kind of machine that used FORTRAN IV was restricted enough that the code couldn't get unmanageably large.
Even a bad language is tolerable when it really only consists of a single calculation in a loop.
I still remember changing an - already obsolete - FORTRAN IV code, and get a compilation error consisting solely of a "?". No line numbers or anything. Just "?".
@jannem @arclight @louisepryor
@gulfie
In my case, the hardware was a CDC 6400 and 6500 in the late 1970s.
They had 60-bit wide words, which was great: single precision floating point was 14 digits! This made teaching numerical analysis a bit interesting, since to convince students that roundoff was a problem, you had to find really nasty examples with exponential error growth and convince them those weren't rare/pathological cases, and a wide floating point word was not sufficient armor against them.
And this was long before the IEEE-754 floating point standard, so there were all sorts of other peculiarities, too.
Weirdly, in retrospect, integers were 1-s complement, so you also had to explain about +0 and -0.
But, to your point: the address space was a maximum of only 2^18 words.
Practically speaking, you could go up to about 256k words, but that would almost grind to a halt all other activity from memory starvation. (CORE memory, expensive!) So any such job had to wait, potentially hours, until the operators felt like they could let it run.
Fortunately, you could calculate the required storage for a Fortran IV program *at compile time*.
There was no virtual memory. But you could do manual "overlays", in which programs get loaded on top of each other. Heaven help you if you kept a reference to something and then overlaid it. That was painful to debug.
256k of 60-bit words is a bit under 2 megabytes in today's parlance. So, yeah: pretty small, and only ran at about 6 MIPs, i.e., something like 1000x fewer instructions per second, even before you think much about modern pipelining.
It was amazing for its day, but now you could probably simulate it on a phone and be faster.
@atomwitch It's weird refactoring code that was written when I was three years old and Nixon was still president.
Just remember, that code still retains the shape of long-gone constraints - hardware, language, budget, programmer experience, and fundamental computing knowledge. It likely was never expected to last as long as it has. Very rarely have I found actual _bad_ legacy Fortran; most of the time it's just inconvenient and neglected, weirdly shaped due to those now-missing constraints. If you can get rid of EQUIVALENCE statements the test of the refactoring should be straightforward unless someone's gone all pathological with GOTOs.
I specced out a book on modernizing old Fortran code a few years ago - no obvious market for it. :/