Advent of Code 2025 in Fortran 77 (mostly)

This year’s Advent of Code was reduced to 12 days of puzzles. Thankfully, as I managed to complete the last puzzle I had outstanding (Day 10, part 2) a couple of days ago. In previous years I’ve skipped puzzles that took me a lot of effort, thinking that I’d have the time to catch up later. Of course, I never did. So this is the first year I’ve managed to complete the whole problem set – and before Christmas to boot.

The Advent of Code 2025 calendar. It shows the Elves' factory under the North Pole with Santa flying across the top in his sleigh. It is animated ASCII art.
24 gold stars and a decorated North Pole in time for Christmas.

I used Fortran 77 this year and stuck to the standard fairly well. I resorted to recursion on a couple of days as writing iterative solutions was too painful to contemplate. I also used bitwise XOR and AND to help solve Day 10’s puzzles.

Back in the 1980s when I was porting Fortran code to various minicomputers and workstations there were f77 compilers that supported both of these extensions, but they didn’t form part of the standard until Fortran 90 was ratified. I remember one instance of almost being held hostage over a weekend by a customer who was getting a crash in our software due to an unexpected recursion in some Fortran code, until we discovered late on the Friday afternoon where the problem was and fixed it. For anyone interested, the computer (and compiler) in question was the Harris HCX1.

My Fortran 77 is pretty rusty as I last used it professionally around 30 years ago. But I think it has improved since last year’s Advent of Code. For example, I’m no longer using COMMON blocks to pass data between subroutines and functions! COMMON has it’s use of course, but not in the relatively small programs Advent of Code requires. Rediscovering list directed i/o has helped reduce the complexity of puzzle input parsing too.

I wrote notes each day as I solved the problems and these are in my repository with the code, so I won’t repeat them here. I was happiest with my solution for day 7. Just about every other solution I’ve seen since I finished (I don’t go anywhere near the internet to avoid spoilers until I have) used recursion, but even for part 2 it’s not necessary to get a well-performing piece of code. On my Pi4B, parts 1 and 2 combined need just 0.08s to run.

The toughest day for me was undoubtedly Day 10. It was the first time I broke with the standard to use recursion, as well as the bitwise operators. The second part took a lot of thinking about, a number of long walks, lots of paper and pen followed by half a dozen aborted attempts at writing the code over several days until I managed to get it to work for the sample data. Even then the puzzle data had a nasty surprise hidden in it that took a quick hack to work around.

For posterity, here is the (final) pen and paper version of the algorithm I devised:

A handwritten piece of pseudo-pseudocode that details my approach to Day 10 part 2.
Day 10 part 2 handwritten pseudo – pseudocode.

Having looked at other Day 10 solutions since, I know that it would never have occurred to me to either use a 3rd party library like many Pythonistas seemed to do, or attempt (what I regard as) the heavy mathematics of Gaussian elimination2. However, I’ve since noticed that someone else came up with a very similar approach to mine several days before I did – and has helpfully provided a tutorial and a proof for the method.

Last year I wrote a quick and dirty insertion sort to help with a couple of the problems. I used the same algorithm again but it really came unstuck against the 500,000+ items that required sorting on Day 83. I hit a similar time sink on Day 9, but this time there were *only* 120,000+ items to sort. As I’ve had some free time since I finished this year’s event I’ve played with a few more (non-recursive) sorting algorithms. Here are the results … unsurprisingly, the heapsort algorithm wins out every time!

Puzzle
(hardware)
Insertion Sort
O(n2)
Bubble Sort
O(n2)
‘Optimised’
Bubble Sort
O(n2)
Heap Sort
O(n log n)
Day 8, part 1
(Pi 5)
68s482s492s0.09s
Day 8, part 1
(Pi 4B)
348s1,180s1,190s0.27s
Day 8, part 1
(Pi 1B)
14,725s5.7s
All hardware running Debian Trixie (Raspberry Pi OS) with gcc (gfortran) 12.2.0

I enjoyed myself more this year than previously, mostly due to the reduced number of problems to solve and the posts from the community of Mastodon ‘Adventers’ all solving the problems in their own way across multiple languages4.

Thank you to Eric Wastl and your team for the puzzles and I hope that there will be a 2026 edition in a little over eleven month’s time!

  1. There appears to be remarkably little information on the internet about the Harris HCX machines. We had the same software running on the Harris MCX workstation (and about 20 other minicomputers and workstations) without it (or them) complaining about this coding error. ↩︎
  2. When I was a computer science undergraduate in the 1980s, I used to joke that computer scientists were 10th rate mathematicians and that mathematicians were 10th rate computer scientists. ↩︎
  3. The book ‘Algorithms’, by Robert Sedgewick, published in 1983 suggests that a sort of 50 items is ‘small’, 500 items is ‘not too large’ and 5,000 items is ‘moderately large’. ↩︎
  4. According to the data from the ‘unofficial’ survey, five people used Fortran this year. We are a hardy breed. ↩︎