> 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 definition of "passable compiler" in 1992 must have been very different from what it is today; while third year students write interpreters and compilers, nobody would call them useful or passable.
for advanced undergrads, the university of michigan (i'm speaking from my own experience here) has a course progression of (1) programming languages for 1st year grad students, (2) compilers for undergraduates, (3) compiler optimization for 1st year grad students. the expectation is that you can write a fast implementation of a simple language (~scheme) on your own, and you have the knowledge to write a simple optimizing compiler for e.g. c89/99 if you were to take it on as a longer project. any compiler written in a semester probably doesn't have enough manpower to be optimized to a point of usefulness, and you'll learn some things only via implementation struggles, but you'll have the capability to try, search for literature to get unstuck, etc. which is cool!
Fortran H was faster than the fastest punchcard feeder of the time. That bottleneck is unfortunately long gone, without the same magnitude of improvement on the other side. (Physical limits, amazing optimisations, etc.)
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.
Beautifully written but when the lack of a better compiler gets attributed to rational actions my brain glitched. That’s not fitting my mental model of how big corps operate at all!
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.
I think the reason writing a compiler is easy today is the theory I learned in compilers class. How to do context free grammars, the concept of abstract syntax trees, the pattern of writing a recursive descent parser and having a lexer that only looks one symbol ahead and has a peek function. On top of that we have experience with lots of languages and type systems to draw from when constructing a new one.
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.
The author is comparing a 1990 hypothetical compiler to a 1970-ish compiler. The late 1960s and early 1970s are essentially when all of the foundational parser theory gets laid down. By the late 1970s, we're getting into autoparallelization and autovectorization research. Monotone dataflow analysis was developed in the 1970s as well. To be a little bit glib, basically what happened is compiler theory is really birthed starting in the 1970s; if you wanted to track down most of the techniques in the Dragon book, I suspect the vast majority of them originate in that timeframe.
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.
I agree with the overall point of the article, but I feel compelled to be _that guy_ and point out that most of IBM's systems programming involved various dialects of PL/I, not Fortran, and they went through a bunch of different iterations on those compilers and their code generators.
I like this. Really paints a picture of what we are progressing towards. The tools we needed to build the tools we need to build. And the fact that it all boils down to getting the computer to do the thing we want it to do and trying to figure out what that is. Makes me hopeful for the future.
> 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.
I think this is still true today. Software is only just starting and there is a lot of room to find better ways of doing things.
> 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.
I don't think this has changed much at all since 1992. Now you can say that it's less than 90 years old, and nobody is very good at it yet.
And most of our profession has already given up on getting any better at it because a machine can spit out code that compiles.
One of the reasons I was so interesting to find this thing I had written was that things had (in some ways) changed so little in thirty years.
Today I was re-reading Donald Knuth's 1974 paper “Structured Programming with go to Statements” where he says:
“At the present time I think we are on the
verge of discovering at last what program-
ming languages should really be like. … My dream is that by 1984 we will see a consensus developing for a really
good programming language (or, more likely,
a coherent family of languages).”
I went to the University of Arkansas in the fall of 1993, into Computer Systems Engineering, and we were the first freshman class to work on C/C++ as a primary language to be learned, instead of FORTRAN. I still to this day haven't written a single line of that language, but I find it fascinating.
20 comments
[ 2.9 ms ] story [ 34.2 ms ] threads/FORTRAN I/Mythos/ for the 2026 version of this.
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.
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.
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.
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.
Nowadays it's all about optimizing the same old algorithms but on a GPU.
I think this is still true today. Software is only just starting and there is a lot of room to find better ways of doing things.
I don't think this has changed much at all since 1992. Now you can say that it's less than 90 years old, and nobody is very good at it yet.
And most of our profession has already given up on getting any better at it because a machine can spit out code that compiles.
Today I was re-reading Donald Knuth's 1974 paper “Structured Programming with go to Statements” where he says:
“At the present time I think we are on the verge of discovering at last what program- ming languages should really be like. … My dream is that by 1984 we will see a consensus developing for a really good programming language (or, more likely, a coherent family of languages).”
Hoo boy, was he ever wrong.
80% of the cost is maintenance, and all software dies so there will always be work to do.