Last time I was working with CCE, I was looking at blistering runtime speeds, but six or seven hour compiles. Huge codebase (40mil+ LoC), and the optimisations were great, but not exactly a fantastic dev lifestyle.
s/FORTRAN I/Mythos/ for the 2026 version of this.
Occam’s razor IBM didn’t invest in Fortran I because the internal political environment at the corporation didn’t have the incentives aligned to do so. This is completely orthogonal to whether they could have used a better compiler or not.
Letting pride outvote usability is an insane business decision.
There is a second shift that occurs around 2000-2005-ish, which is the transition of optimizing compilers from an instruction-based semantics to a more value-based semantics, in that modern optimizers make no real attempt or guarantee to preserve the structure of code. For example, an if statement may happily be converted into an expression lacking an if entirely.
- not writing compilers in assembly
- not requiring overlays
- knowing how previous compilers produced fast code (Web search doesn’t give me conclusive answers, but that Fortran compiler may have been the first to do loop unrolling and common subexpression elimination)
- having way more memory, CPU and disk available
- possibly: spending less time looking at optimizations. I expect IBM tried hard to make the output of their compiler to match the performance of hand-written assembly
The best link I could find is https://en.wikipedia.org/wiki/Fortran#FORTRAN_IV:
“In particular, the FORTRAN H compiler played an important role in the development of certain kinds of optimization approaches, such as allocating a specific set of registers to hold the values of variables while in a loop. Overall, the compiler had three levels of possible optimization, as Fortran compiler developers had learned early on that the ability to turn off optimization was a necessity, since it drove up compilation times considerability for program runs that often were not going to work anyway. Even with the larger amount of main memory available to it, the FORTRAN H compiler was still organized via a number of overlays.”
I was just doing some research and apparently all of this stuff was invented around the late 60s and so in the 70s it was still new and by the 90s it was standard practice. The dragon book came out in 1986 and spelled it all out in one place.
Today we have the benefit of knowing the right ideas to use from the start and confidence that if you follow the formula it will all work out.
>> - not writing compilers in assembly
Sure, but you still generate the machine code, right? You still have to master the instructions and their specifics of the target CPUs.
Aside from a few utilities, relatively little of OS/400 was written in RPG. Originally, most of it was written in two different dialects of PL/I. Some Modula-2 was added into the mix, and most of the lower levels were rewritten in C++ when they switched to PPC processors.
You do, but self-hosted compilers tend to have two huge benefits:
1) they tend to be easier to reason about, being written in a high-level language
2) they exercise the code, and usually even seldom-used parts of the code, to make problems more noticeable
In the 1970s, it would have been really low on my list, likely below using a macro assembler.
Thu, 18 Jun 2026
My 1992 view of the problems of computer programming in 1992
While cleaning out my office today, I found this, which I wrote in 1992:
In the middle 1970's, the IBM corporation did (and perhaps still does) most of their in-house programming in a computer language called FORTRAN. They had a pretty good FORTRAN compiler, called the FORTRAN G compiler. It was fast at translating FORTRAN into machine instructions, and the machine instructions it produced implemented the desired behavior fairly efficiently. Nevertheless, IBM decided to write a new compiler.
This was very daring in the middle 1970's, because compilers were quite complicated programs, and are difficult to write, and it was surprising that IBM was willing to invest the vast resources that a new compiler would require when an adequate compiler was still available. IBM spent millions of dollars and hundreds of programmer-years, and produced the FORTRAN H compiler, which was fast, efficient, and full of nice features. It was an excellent compiler and is still the one that they use.
Here is the first punch line: Compiler programs are no longer difficult to write. The past fifteen years have seen an enormous increase in our understanding of compiler technology and how to write a compiler. Compilers are so easy to write now that third-year undergraduate computer science majors are expected to be able to turn out passable compilers in one semester.
Now a question: Since we're obviously thousands of times better at producing compilers than we were fifteen years ago, so much so that a single undergraduate can write a passable one in four months, why hasn't IBM invested millions of dollars and hundreds of programmer-years to produce a super FORTRAN I compiler that's thousands of times better than the FORTRAN H compiler?
The answer is that compiler program quality is no longer the limiting factor on our ability to write computer programs. The problems that programmers face no longer have to do with how good the compiler is. Instead, they are problems of method and language. We don't really know how to program yet, or how to manage our programs. We don't really know what we want to say or how to say it. We don't have good computer languages for expressing what we want to computer to do. We don't know how to think about programming. In short, the reason IBM doesn't bother with a super FORTRAN I compiler, is that no matter how good it was, it would still be FORTRAN.
Computer programming is still a black art. It's less than fifty years old, and nobody is very good at it yet. We can make better tools than we know how to use.