I just saw a post by "Kenny Logins" that read "Fortran favors the old" and I'm pretty sure that's the best thing I may read today or maybe this year.
Aside: I once considered forming an ops consulting service called "Age Against The Machine". I kind of regret not doing that.
@arclight Wait doesn't it get better the longer you wait to start it?
@arclight
It's not too late. If you do, count me in.
(There's Y2K038 work just around the corner, and there was just a 2019 GPS rolloever Windowing solution hiccup this week. I'd rather do Perl archaeology p/t, but whatever, I did almost everything once already.)
@arclight Kids today have a different understanding of “software engineering”. I learned software engineering from actual engineers who wrote software, and left their code for me to study like biblical texts.

@arclight

*blinks*

I haven't wielded Fortran in anger for more than 45 years, but this really smacked me in the face with self-recognition.

@weekend_editor @arclight about 37 years for me. I dare say fortran 77 is outdated now! But thinking about it really brings back memories...
@louisepryor @weekend_editor Modern Fortran is surprisingly not awful. :)

@arclight @louisepryor

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. :)

Bob Apthorpe / Castlequest · GitLab

GitLab.com

GitLab
@arclight @weekend_editor @louisepryor unexpectedly discovered some COBOL files in the repository for the Java web application I’m currently working on updating and migrating. That was quite the surprise. Maybe I’ll find some FORTRAN next week…
@arclight sounds like brenda baker’s struct program might have helped! https://github.com/arnoldrobbins/struct
GitHub - arnoldrobbins/struct: The Research UNIX struct(1) program

The Research UNIX struct(1) program. Contribute to arnoldrobbins/struct development by creating an account on GitHub.

GitHub

@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.

@arclight I'm so old I used to program in FORTRAN and now you are asking me to believe this was good fortune? :-)
@arclight I am currently wrestling with some Fortran code that is significantly older than I am and I feel this deep in my soul.

@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. :/

@arclight Ah that's a bummer! It's the kind of thing that I'd love to read - both for professional reasons and because I love reading historical perspectives on this stuff
@atomwitch I'll send you a copy of the book proposal - it might help even if all it does is provide moral support :)
@arclight FORTRAN; favors the COBOL; I C.