Advent of Computing - Episode 23 - FORTRAN, Compilers, and Early Programming

Episode Date: February 10, 2020

Our modern world is full of software, it's what makes everything tick. The sheer amount of code that goes into something like keeping the internet running is staggering. Programming isn't the easiest profession, but there was a time when it was much much harder. It took a huge shift in thinking, and some impressive feats of software development, to make complicated programming possible. And that shift started in the 1950s. Like the show? Then why not head over and support me on Patreon. Perks include early access to future episodes, and stickers: https://www.patreon.com/adventofcomputing Important dates in this episode: 1951: Grace Hopper Creates A-0 Compiler 1954: John Backus Starts FORTRAN Project at IBM 1957: First FORTARN Compiler Ships

Fortran. If you're a programmer, then you've probably at least heard stories about it. If not, then let me introduce you to one of the first programming languages ever developed. Since its creation in the mid-1950s, Fortran has gained quite the reputation. Part of that is thanks to the fact that, for the past 60 plus years, the language has been in constant use. 60 plus years, the language has been in constant use. Sure, it's not as popular as it once was, but you don't have to look very hard, especially in the sciences or engineering, to run across piles and piles of Fortran code. The clout that follows the language around is pretty mixed. For one, it's archaic. There are quirks to the language that are holdovers from the days of punch cards. The fact that a Fortran project can contain code from decades ago means that often a new

developer may be faced with bizarrely antiquated code. Outside of any technical complaints, the language just feels plain alien compared to modern code. Some even consider using Fortran as harmful or damaging in the long term for programmers exposed to it. But all that being said, Fortran also has a reputation for being wickedly fast at doing math. That's all I knew about the language for years and years. Then, as fate would have it, I found myself face-to-face with Fortran. I was working at a certain unnamed research lab and found, as somewhat of a shock, that most of their code was written in this venerable language. And so, over the course of

a few months, I became just one more of Fortran's victims. I found out firsthand that all of the rumors I heard for years and years, well, they were true. At first, it felt like trying to talk to a computer through some lost ancient dialect. Fortran's hard to use, there's no sugarcoating that, and it's also hard to learn. But it is really good when it comes to running calculations. In fact, more recent versions of Fortran specifically are almost the lingua franca for supercomputing. But as I was exposed to more and more Fortran, I started to find out something else for myself. If you know where to look,

you start to see some familiar lines tucked away. And you start to realize that that stray recognizable chunk of code is no mere accident. Yes, Fortran itself is still being used in 2020. But the fact is, in almost all programming languages, no matter how new, how popular, or how ostensibly removed, you can still see chunks of Fortran's influence. Fortran is one of the mother tongues of programming, without which our modern computerized world would be radically different.

But there's a bigger story here than just that. There's the story of how programming languages, and really our modern conception of a programmer, came to be created. In reality, Fortran would just be one step along that journey. Welcome back to Advent of Computing. I'm your host, Sean Haas, and this is episode 23, Fortran, Compilers, and Early Programming. Today, we're going to be taking a look at the development of the first widely used and, frankly, one of the most long-lived programming languages. But along the way, we'll be doing more than just talking technical jargon. The development of Fortran and other early

programming languages led to a fundamental change in how computers were used, and really how computers could be used. Even if you aren't a programmer, you still benefit from this shift every day. When you get down to it, the fact that we're able to have such sophisticated computers in the modern day comes down to the rapid pace of development in the field. Many advances had to be made just to keep step. And one of those steps, maybe better termed as a leap, was the development of high-level programming languages. Without that advancement, it's likely that progress would have stymied for years or decades. And Fortran was at the forefront of a lot of this leap.

But it wasn't the only step on this path. At the dawn of computing, programming languages didn't really exist, at least not in a recognizable form. That would persist for decades, and would take a monumental effort to change things. Over the course of the 1950s, a rotating cast of programmers would slowly start to push the status quo in a new direction. There would be a lot of resistance from the community at large, partly out of disbelief in new methods, and partly out of a sheer unwillingness to change things up. Even outside of that, creating a whole new field and a whole new way of thinking about computers would be a monumental task. Luckily for everyone who uses a computer nowadays, there were some heroes that were up to that job.

So today, we're going to be talking about Fortran. Ultimately, it would be the first programming language that would gain popularity. But to get up to that point, we're going to be looking at the time before Fortran. What it was like to program without a language. we're going to be looking at the time before Fortran. What it was like to program without a language. We're going to be looking at some early attempts to address the problems that programmers faced in the 50s, and how that primed the stage for the shift necessary to make Fortran even possible to begin with. And then, finally, we'll look at the creation and the early adoption of Fortran. In the early 1950s, the concept of a computer programmer was

a lot different. At least, it wouldn't be what we're used to today. You couldn't get a degree in computer science until 1953, and the first full computer science department wasn't founded until 1962. Most people who ended up working with computers were something like a mix of electrical engineers and mathematicians. To really do much with a computer, you had to know how that specific machine worked inside and out. Therefore, a lot of people who programmed machines were the same type of people who designed those very machines.

There wasn't such a thing as someone who just programmed a computer. At least not yet. Part of the reason for this was due to the fact that just so few computers existed. There were a lot of people behind the development of early computers, but overall, the community still wasn't very large. Most computers in the 40s and early 50s were completely one-of-a-kind creations, like the Mark I or Whirlwind. Things would start to change in 1951 when Sperry-Rand's Univac I, the first mass-produced computer, started being sold. Even then, there were only ever 46 Univacs built. All this is to

say that it wouldn't be until at the very earliest, the mid-50s, that the profession of programming became separate from the profession of designing and building computers. So what would it have been like to program one of these machines? Well, in a word, difficult. The bottom line is, computers don't speak anything close to how people think about problems. If you ask a computer, hey, what's 2 plus 2, it wouldn't understand you. In fact, it might even turn off. What computers do understand is a little something called machine code. Of course,

every system is different, so this is just a generic name for the binary code that a computer can actually read and run. This is a set of simple instructions that are encoded as numbers. And I have to stress that each instruction only does one very simple and very particular thing. A usual instruction set will have things like put this number at this location in memory, or load this number to operate on, or add this number to that number, maybe jump to this part of the program, or compare this and that number, and so on. Usually there'll be a few hundred instructions maybe. In order to get anything done, you have to use a whole lot of instructions. Depending on how complicated your task is, you may have to use thousands or maybe millions of these tiny instructions.

And even once you figure out how to get the computer to do what you want, you still have to translate that into the machine code that it will actually understand. So, what was this like in practice? Well, let's take a look at the aforementioned UNIVAC-1 as an example. Let's take a look at the aforementioned UNIVAC-1 as an example. It was designed to be relatively more easy to use than its contemporaries, so I think it'll give us a best-case example. That, and for the time, most programmers would have known how to program on the UNIVAC. The first step was planning the program. You'd have to write out by hand, on paper paper what you wanted the computer to do,

step by step, and eventually instruction by instruction. Once that was worked out, you'd then have to translate it, still by hand, into machine code. For Univac, that was made a little bit easier since the machine code that it used could be represented as alphanumeric. Each instruction started with a letter. A was add, D was divide, and so on. Instructions were just a little easier to remember so you didn't have to look at a table and documentation to figure out what number to use for what instruction. For small programs, this may be a pretty quick process, but it would slow down considerably as the program got

larger and larger and more and more complex. But you couldn't run your code on your computer just yet. Programming instruction by instruction was well known to be very error prone. And computer time wasn't really in surplus, so it was important to ration it accordingly. That meant that you couldn't run your code on UNIVAC until the program you were written was believed to actually do something useful. From Adele Mildred Cross, a programmer who worked on UNIVAC computers extensively in the 50s, quote,

Because available computer time for program testing was precious, programmers couldn't routinely use the computer to check their code as they do today. Two different people would check each other's program to ensure that it would execute without error. That's right, the first pass of debugging code was done by hand by a co-worker. All this, the planning, converting to machine code, and initial testing is done without ever touching machine. Everything is just written in somewhat readable machine code with pen and paper. Assuming that you get your program to pass the eyes of a co-worker and everything looks good, then you could line up to run it on the precious Univac. But once you get to this step, you have some options. Computers in the day didn't have such

a thing as text editors. You couldn't just type in your program and run it. Instead, Univac's primary input was done via a massive desk covered in switches, lights, and some fun knobs. From this desk, you could enter in your program one instruction at a time by flipping switches that would slowly load data directly into Univac's memory. Every time you ran a program this way, you'd need to re-enter it, so it's not very convenient. But there was another option if you wanted to keep around a copy of your program for later use. UnivAC could also read in programs on magnetic tape. Think of a fancy and very expensive reel-to-reel tape machine. You can't

really write directly to tape though, but most UNIVAC installations came with some support machines that could help along the way. So to make a tape, you had to, using a card punch, enter your program in on a stack of punched cards. Then, those cards would be transferred from paper onto a magnetic tape using another machine. Finally, you could load the tape into Univac and run your program. But, it's not over yet. This is just the beginning. If your program has any problems, then you were in for the real treat and real time sink of this method. Debugging had to be done by hand.

Remember, the computer time was very expensive in the 50s and there weren't many utilities to even help with debugging. So you'd get to go all the way back to the first step and write your program again by hand and then debug it with a co-worker if there were any problems with your code. And remember, you have to write everything in machine code, which is already complicated and error-prone to begin with. More often than not, your program wouldn't work the first time, so anyone on Univac would get pretty used to this cycle. Programming in this era wasn't really for the faint of heart or those who had any time constraints. The problem here went beyond mere annoyance. It was downright expensive to program this way. I mean that in a very, very literal and monetary sense. One of the reasons that computer time was so well guarded, besides the scarcity of computers,

was that most organizations that used computers didn't own the hardware. At this point, machines were a huge investment. Adjusted for inflation, Univac 1 would have sold for over $7 million. And that's just the computer, that's not counting any of the peripherals that you need to really get a lot of use out of the thing. Some installations were owned outright, but most were actually paid for on a rental basis. On top of the cost of all the hardware was the cost for the staff to keep the machine running. Every second on Univac had a direct monetary cost, and it wasn't a trivial one. a direct monetary cost, and it wasn't a trivial one. Factoring in the cost of paying programmers and the overall expense of developing software really, really starts to pile up.

In some situations, that cost may have been acceptable. But remember, the programming univac was a struggle. It was a very long, drawn-out process. Even before you got your code into the computer, countless human hours were spent in writing, translating, and double-checking your code. Still more time would be spent debugging, and if a bug was particularly hard to spot, a lot of computer time and computer money could be wasted. That's the general wall the computing started to run into in the early 50s. As I've said, it wasn't insurmountable in itself. It was manageable, but to a point. But specific circumstances made things a lot worse. It may seem a little mundane to us looking back, but the last straw that would bring this delicate

situation to a point turned out to be dealing with decimal numbers. Believe it or not, most computers, especially these primitive beasts, aren't good at running fractions. Math with whole numbers was easy. That had always been part of computing. But decimals were a real sticking point. Later computers would end up really standardizing the hardware for dealing with decimals, or in computer speak, floating point arithmetic. But at this time, computers were just starting to adopt floating point. There were some machines and research that could do it, but UNIVAC definitely wasn't one of them. And since computers like the UNIVAC couldn't handle doing decimal math on their own, that meant that the

task fell down to programmers. With some careful code, it is possible to do floating point math with only whole numbers. That is, if you're careful. Once your program gets turned into machine code and then mixed around in the computer, that careful consideration and planning can pretty easily get scrambled. It turns out that writing floating point software was one of the more difficult and, accordingly, more error-prone things that you could do on these early systems. So if you wanted to do something like, say, division, or calculating anything with much accuracy, that was going to cost you a lot of time and a lot of computer hours.

Luckily, this problem was solved. It turns out that to do so, however, would take looking at computers in a totally different way. Often, we talk about accessibility in computing, the slow march that machines have made from incomprehensible beasts locked away from the public to the eventual user-friendly devices that we know today. But that's been a force ever since the beginning, but not always in the way that we'd recognize. But that's been a force ever since the beginning, but not always in the way that we'd recognize. One of the ways that this cost of programming problem was solved would turn out to be by making computers more accessible for programmers. Even in the 1950s, this programming cost was a well-known problem, and few were more familiar with this issue than Rear Admiral Grace Hopper.

I like to think of this whole era in computing as a sort of wild west. Like I said earlier, the programmers and computer scientists of this era were from a diverse set of backgrounds. They were a lot different from programmers that would, even a decade later, start to appear on the scene. And Hopper is one of those people. Her first career was as a mathematician, earning a PhD at Yale before becoming a professor at Vassar College. Her introduction to computing was through a somewhat strange path. Hopper was 34 when World War II started, which was too old to enlist. And as a professor, her work was already considered an important part of the home front. But a big part of what makes Hopper an interesting

figure is this particular determination she had. When she decided to do something, she followed through. And in 1943, she decided that she wanted to join the U.S. Navy. And of course, she was rejected, at least initially. That year, she would end up leaving Vassar and joining the Naval Reserves. After some shuffle through the bureaucracy and training, she found herself stationed at Harvard. And that is where she came face-to-face with the Mark I, also known as the first electronic computer ever built in the United States. It may sound strange to sign on with the military and end up working on computers, but it was

an important cog in the worm machine. Hopper learned how to program the Mark I and would end up becoming one of America's first computer programmers. Most of her work came down to running calculations for the military. This would be things like computing missile trajectories or working out fuel usage, that sort of thing. Her code would even end up being used in parts of the Manhattan Project. And by the end of the war, Hopper would be instrumental in building the Mark II, another very early computer. All this is to say is that during this era, Hopper knew computers

better than almost anyone in the world. And she was intimately familiar with how difficult programming, specifically programming floating point math, was. You can even see this in some of her earliest work. The Mark II, the computer that she would co-design, included specialized hardware for floating point handling as well as complicated mathematical functions such as square roots and logarithms. That wasn't something that would be common until decades and decades after the Mark II. After her work at Harvard, she would leave the Navy, at least for the time being, and join Sperry Rand. The company was just starting to design UNIVAC- 1, and Hopper would be an early addition to the team. It would be while working at Sperry Rand that she started to look for a

better way to program. Her actual role at Univac was the Director of Automatic Programming, and that's a title that's now full of some pretty antiquated language. I've already mentioned that the issue of programming cost was well known by the 50s. So-called automatic programming was one proposed solution in this period, but it's not a term that's used often in modern parlance. Automatic programming would come to encompass a large swath of differing and sometimes contradictory methods. But in the UNIVAC world, it was essentially the practice of building up a library of reusable code. Programmers quickly noticed that there were some computations that were being done over and over again all throughout their programs. Things like square roots, trig functions, or even just printing something out to the printer.

By packing up all these repetitive tasks into something like a library of functions, or even just printing something out to the printer. By packing up all these repetitive tasks into something like a library of functions, a programmer's life could be made a little bit easier. Instead of having to rewrite the code to run a square root hundreds of times, you could just call up the proper function. But there's still a good reason that things progress beyond that. In these early implementations, you couldn't just say, give me the square root of 8. Instead, each function had some number assigned to it. So you would still need to look it up in some dusty table and then plug that number into a little bit more machine code to make it all run properly. It was an incremental improvement and it helped, but it didn't address the core problem. Now, Hopper was never one for

incremental improvements. She had already been using libraries or something close to them since before joining the Univac team. While it worked, it was still limiting. It kept programmers down on the machine level, programming by numbers and symbols. In Hopper's opinion, quote, level, programming by numbers and symbols. In Hopper's opinion, quote, it's much easier for most people to write an English statement than it is to use symbols. So he decided that data processors ought to be able to write their programs in English and the computer would translate them into machine code, end quote. And that is less of an incremental improvement and more of a shift in how people would use a computer. Of course, Hopper wasn't talking about having a conversation with a computer.

Instead, she was looking to find a way to hand-wave away all the bits and wires inside of the machine so that a programmer would only need to worry about programming. programming. To use the earlier example of working on Univac, Hopper was looking for a way to go straight from writing out your program to running it on the machine, with all the intervening steps removed. This would, confusingly enough, also be called automatic programming. But today, we would know this as a programming language. And Hopper was one of the first people to arrive at the idea of this solution. And this sounds great. Who wouldn't want to make programming more simple? The gains would be huge. There's just too many to list. However, this was totally new territory, and it would take an almost inhuman feat of programming to accomplish this with the systems

of the day. I've seen it simplified to, quote, computers don't speak English, but I think that's missing the point. Early computers weren't really equipped to deal with text data. They were built for math. Processing text was doable, but it wasn't done on a huge scale. It definitely wasn't done with the complexity to enable programming all via text. Hopper's solution was to create a tool called a translator. Nowadays, we'd know this as a compiler, but I like the old name a little more. I think it's more evocative of what it actually does. Her plan was to create a program that could translate something that a human could understand into machine code that a computer could understand.

In this way, Hopper flipped the problem somewhat. She wouldn't so much teach computers English, instead she'd build a way to turn English into machine code. Hopper's translator, sometimes called A0, sometimes just called the A-system, would be a program that would create another program as its output. Now, that may sound kind of weird, and it is. Compilers are one of the most complex pieces of software out there. There just aren't many other programs that act like this. But, believe it or not, there was precedent for this sort of thing,

even this early in the history of computers. And as luck would have it, that precedent was a program written by Betty Halberton, one of Hopper's co-workers at Univac. Halberton had previously been involved with ENIAC, another early computer, before joining on with Sperry Rand. For our purposes here, what matters is that while working on Univac, she wrote a very, very efficient sort function. Given a dataset and some information about that data, Halberton's sort function would spit out a specialized program tailored for sorting that specific data. Being exposed to this kind of thinking gave Hopper the final push she needed to get started. Quoting Hopper once again, quote, I'm not sure that I would

necessarily have gotten done what I did get done if she hadn't been ahead of me, so to speak. Knowing that she had used a program to generate a program, I had a good deal more nerve to go ahead and build the first A0 compiler, end quote. The actual creation of the first compiler, A0, was started by Hopper in 1951. You may be wondering why I haven't been referring to A0 as a programming language, and there's a good reason for that. Strictly speaking, Hopper didn't yet have a programming language on her hands. But she did have a compiler. Let me unpack that a little since I think this is an important point. A0, and for that matter, the following A1, A2, and A3 versions of the compiler weren't equipped for general purpose programming.

One factor here is that the A series of compilers were all built for math only. Most functions were for carrying out things like addition, logarithms, and the like. The other large factor is that programming for one of these compilers was still relatively close to programming directly on Univac. Instead of a new and distinct language, Hopper had built up a sort of bridge between the programmer, a library of functions, and the eventual computer. So what did this actually look like? Here I'm going to be going off the documentation for A2 simply because that's what I was able to dig up most easily. It seems that there isn't much of an existing paper trail for the earlier iterations.

So to compute the square root of some variable A and store it in some variable B, you'd use SQR A B. Simple. But you need to make a few changes for the compiler to properly compile that. A2 can't handle named variables. Instead, you just need to give it the location in the computer's memory where you're storing that data. Also, most instructions take three arguments. Therefore therefore you need to add a dummy argument. So the instruction becomes more like sqr 001 000 002. To our modern ears, that's pretty obtuse. But for the time, this was a pretty big leap forward. Hopper's compiler would take that line of code and turn it into a dozen more instructions

that UNIVAC would understand. But a square root rarely returns a whole number, so Hopper's compiler also handles everything in floating point. By handling the translation, her compiler made programs not only faster to program, but a lot less error prone. Instead of having dozens of opportunities to mess up a square root routine, a programmer would only have one point of failure, and that translated into a lot of time saved. The other huge change that Hopper enabled was a shift in accessibility. She looked at computers in a much different way than her contemporaries. Quoting Hopper again, quote, no one thought of that earlier because they weren't as lazy as I was.

A lot of our programmers like to play with bits. I wanted to get jobs done. That's what the computer was there for, end quote. Computers were, in her view, a tool. There wasn't a reason to get bogged down in the minutiae if you were trying to calculate something. So why should there be any barrier to entry for computers? In a lot of ways, this was the start of the modern programmer. It would take time, but the seeds were already planted. Using this type of view, a programmer could escape from the minutia and just do their job. And more and more people would be able to program without needing as much experience as someone like a Grace Hopper. Once she let the cat out of the bag, so to speak, many other programmers would

follow her lead. In the following years, similar systems would start to appear, but none would really take off, including Hopper's compiler. These were still the very early days, so there were a lot of kinks to work out. The largest one, and what kept programmers of the day away from automatic systems, came down to performance. Sure, it was a lot faster to write and debug programs written for the A-series of compilers, but the final program those compilers produced ended up being pretty darn slow to run. While programming directly in machine code was more error-prone and a lot more time-consuming, the practitioners of that art knew all the tricks to make their programs run as quickly as possible. And despite the benefits of a compiler, the performance hit made them a really hard sell at the time. It would take another monumental effort for programming to

finally change for good. A golden age of programming was about to dawn, and Hopper would be instrumental in its creation. The final step to get programming languages rolling would be done by another team of programmers, and it would come by the name of Fortran. John Backus may have been, at least in his disposition, nearly the opposite of Grace Hopper. His life before entering the realm of computing is often described as somewhat scrambled. While he didn't have the white-knuckle determination of Grace Hopper, he did have a deep curiosity, and that would rear its head throughout his career. He would stumble his way through prep school, eventually enroll at the University of Virginia as a chemistry major, and soon thereafter, flunk out of the program.

Backus was considerably younger than Hopper, so when World War II came around, he was drafted. But once in the Army, he took a similarly meandering course. He started a service assigned to an anti-aircraft detail in Georgia, but would quickly find himself back in a classroom. The war effort took many different forms in this period. For Bacchus, a surprisingly high score on a medical aptitude test pushed him into a pre-med program at Haverford College. While in med school, it was discovered that he had a bone tumor growing on part of his skull. discovered that he had a bone tumor growing on part of his skull. That section of the skull had to be removed to excise the tumor, and a metal plate was fashioned to replace the missing segment of his skull. But the plate wasn't really up to the standard Bacchus wanted. It didn't fit quite

right, and he didn't think that it felt solid enough. So he decided that it would need to be replaced. He ended up finding a clinic in New York that specialized in this kind of bone implant. His last act in his medical career was actually designing his own metal plate that was later implanted in his skull. Backus had wound up in New York City almost by accident, or at least the string of events leading up to him being in the city were pretty coincidental. By 1950, he had already gone back to school and graduated from Columbia University with a master's degree in mathematics. And it wouldn't be until after he received his degree, ending his medical career and the end of his military service, that he came face to face with his first computer. Once again, he came to this almost by accident. To quote Backus from an interview for the Computer

History Museum, quote, I had just gotten my master's degree from Columbia, but I hadn't even begun to look for a job. But I just found this place and I walked in and it looked interesting. I asked if they would give me a job, end quote. That place ended up being IBM. Backus had probably just wanted to get some contact information, maybe find where he could drop a resume, but that wouldn't happen that day, quoting Backus again. And they said, yes, come up and see the boss. I said, no, no, no, I've got holes in my sleeves. I have to look respectable.

But they got me up there anyway, and I got an interview with Rex Sieber, who gave me a little puzzle that I solved, and he hired me." To note, Sieber there is the co-creator of IBM's first mainframes. Just like that, Bacchus found himself working as a programmer at one of the most influential computer companies in the world at one of the most pivotal times in its history. He was coming into a field a good deal later than Hopper. In those seven or so years between Hopper's start on Mark I and Backus joining IBM, computing had already changed significantly. But importantly for our story Bacchus started programming before any compilers were released from Hopper or from others he got to experience the convoluted process of programming

unaided firsthand and that led him down a very interesting path no IBM computer up to this point had any floating point hardware that's a thread that I keep coming back to because it's an important and limiting factor for programmers of the time. It's one of the reasons that automatic programming systems were so enticing in the first place. In the wake of Hopper's A-series of compilers, the programming community became abuzz with possibilities. It was proven that a better way to program was possible, so it became a race to create a practical solution. Backus would even delve into the fray and make his own math-oriented automatic programming system. Called speed coding, it was first announced in 1953,

but never amounted to much outside IBM. Even at this point, Backus was already aware of the issues with the state of programming. I think he articulates it best like this, quote, since this floating point speed coding calculator is slower than the 701, despite the convenience that it offers, you might ask, why go to a lot of trouble to make an extremely fast calculator like the 701 behave like a slower one. End quote. The IBM 701 mentioned was the current top-of-the-line computer that IBM offered. Taking that hit in performance would greatly reduce the cost of programming. But the fact of the matter was that in 1953, few people were willing to accept that new cost. It was trading in one problem for another, and with

the current state of technology, there just wasn't an easy way to get around how slow these early compilers were, especially when it came to floating point math. For a programming language to really take off, at least in Backus' estimation, it would need to have a one-two punch. Hit one would have to be performance. Everything should translate down to machine code as fast, or at least close to as fast, as handwritten code. The knockout blow had to be improved accessibility. The language would need to be as close to English as they could make it. Up to this point, all other attempts had still been relatively similar to machine code.

They were definitely an improvement, but they were still written instruction by instruction. A fully realized programming language would need to be much easier to write in. It would have to be usable, even if you didn't know everything about the underlying computer. Ideally, an engineer or mathematician could use it, not just a computer scientist. In 1953, many didn't believe that this was possible, and they may have been right at least for that time. It's easy for us to think of hardware and software as two almost entirely separate realms. A user rarely sees much of a difference between this computer or that, and a lot of programmers today would be hard-pressed to tell exactly what kind of computer their software was running on. That bifurcation didn't always exist. For most of the early era of computing, the story of hardware and software are

inextricably tied together. And I think a good example of this comes down to the final spark that made Fortran, and really the dawn of more complex programming languages, really possible. The IBM 704 mainframe was announced in 1954. It had become a pretty popular machine, and part of that is thanks to its built-in support for floating-point arithmetic. There were computers before the 704 that could handle decimal math, but the IBM machine would be one of the first commercially available computers to offer that particular feature. Backus was part of the team that designed the computer, and throughout the project, he lobbied really hard for floating point. This one feature on its own wouldn't be the magic

bullet, but it did put a big dent in the performance problems that automatic programming was facing. In all likelihood, the addition of floating point math plus a few other small improvements made by the 704 made the programming problem a lot easier to tackle. At least easy enough that it could be beaten. By January of 1954, Backus would start work on Fortran, short for Formula Translator. With full backing from IBM management. He and eight or so other programmers, each accomplished in their own right, set up shop at IBM's New York headquarters and got down to the business of designing a programming language.

And, well, from the beginning, the team was already in totally new territory. I've been using the term automatic programming so far in this episode because that's what systems like Fortran or A2 or speed coding were called when they were new, but that's an anachronism. Today, Fortran's more well-known as the first high-level language, meaning that it does away with a lot of the smaller details of a computer and instead uses an English-like interface. In 1954, that was totally new. A2 and other early automatic programming systems had still looked roughly like machine code, like I've been hammering home. From the start, Mac as in Co. knew that Fortran would have to be a lot different. But there wasn't much of a guide

for this type of design yet. How do you make a new language that humans can understand and you can translate easily to run on a computer? Well, the crew at IBM found a little bit of a way around that. They decided early on that making the final program fast was a lot more important than making the language pretty. So the language was put together in a sort of ad hoc manner. To quote from Backus again, as far as we were aware, we simply made up the language as we went along. We did not regard language design as a difficult problem, merely a simple prelude to the real problem. End quote. We need some loops? Well, let's add do-while loops. Gotta output raw data? Well, let's add print. This is a big reason why Fortran looks so strange compared to later languages.

The actual language wasn't part of some grand plan. As long as it was understandable and could be made to run fast, anything was fair game. That being said, Fortran was a sea change when it came to usability, especially when it came to the formula part of the language. Expressions were built in such a way that anyone who's ever used a calculator or written a math equation can program an equivalent in Fortran. Let's stick to the square root example again. To take the root of some variable b and store it in some variable a, you just write a equals sqrt. That's it.

The Fortran compiler handles all the thickets of floating point math, calculating the root, and even where a and b should be stored in memory. Everything is translated down to efficient and fast machine code from just one line of Fortran. A preliminary specification for the language was done by fall of 54. This outlined the overall plan for Fortran. By this time, all the syntax, basically how the language would look, was already set in stone. Named variables with some restrictions, a large library of mathematical functions, lists, matrices, loops, conditionals, and input-output routines made up the bulk of this prototype version. At this point, nothing had really been developed yet, at least compiler-wise, but the team was already accounting for the limitations of the 704 mainframe that they would be using.

The most obvious aspect of this were the input-output routines. When it came to getting data in and out of the IBM 704, you had, well, a printer, a punch card reader, and magnetic tape. So Fortran had all the appropriate functions to use those peripherals. But the limitations of those devices also show up in a more impactful way. Each line of Fortran code can only be 80 characters long, a little less when you account for some formatting columns. This is because punch cards, the most common input for the 704, were only 80 columns wide. The use of punch cards also limited which characters could be used, since only so many different characters can be represented by a single column of a card. The spec was, as Backus had assumed, the easiest part of the project. It was quickly approved by the higher-ups at IBM,

and the real work would begin. That would be the compiler. The entire Fortran crew knew that, much more than the language itself, this would be the real make or break. As with Hopper's original compiler, this would be where some real inhuman feats of programming would come into play. The Fortran compiler itself would take a couple years to get off the ground, but in that time, the eight programmers assigned to the project would create possibly one of the more complex programs ever written up to that time. At its core, the compiler ended up exploiting a bit of a loophole in the programming cost problem at hand. The language had to be usable, and the final code had to be fast. But compile time, well, no one even knew what that was yet. So the Fortran compiler could afford to be as slow and hulking as the team wanted.

While initially planned to work out in three major steps, by the end, the compiler would have six separate phases, each programmed by a different part of the team. As a program worked through the pipeline, it would go from the original Fortran code to an intermediate program, be slowly optimized over multiple steps, and then finally turned into a runnable machine code. The methods used for all these optimizations are pretty impressive, even to this day. One whole phase was devoted just to applying tricks to make array and matrixes a little bit more optimal to use. Another section broke down the program into chunks, simulated each chunk of code for different possible parameters,

and then used the results of that simulation to figure out how best to use registers in the final program. This is all very, very intricate work, and there wasn't a programming language to do it in. Everything was written in machine code, which makes this all the more impressive. By 1957, early versions of the compiler were already starting to work. All the optimizations made during development were really paying off. Once compiled, Fortran code was nearly as fast as handwritten machine code. But it wasn't just the team inside IBM that knew about the new and exciting programming language. The Fortran project was well known to the community at large, and many companies with

IBM hardware were already clamoring to get a copy of the compiler for themselves. They wouldn't have to wait long. Over the course of 57, the first programming manuals were written, and the bugs were squashed out of the translator. Pretty soon, IBM would start to ship Fortran out. The largest hurdle had been passed, but the road was still a little bit rocky. One of my favorite anecdotes from this era has to do with the first copy of Fortran that ever ran outside of IBM. You see, the original plan was

to distribute the long-awaited compiler as a deck of punched cards. Each stack would contain roughly 2,000 cards of binary data in all. Every 704 installation was slated to get a copy. At the time, that would come out to a little under 50 sets of cards. So, one evening in April, just before the scheduled release, part of the team sat down and started duplicating punch cards. By the end of the night, they'd made a grand total of two copies of the Fortran compiler deck, pretty far away from their target. There were problems copying that many cards at once, so the plan was scrapped. It was decided to instead send out magnetic tapes. But what happened to the two completed Fortran decks, you may ask? Well, somehow, one got sent out. It was probably by mistake, or maybe an overly helpful office worker saw the finished deck and figured it was about time to start handing out copies of the compiler.

So, the deck got mailed to Westinghouse, one of IBM's clients with a 704 mainframe. The package arrived a few days later. Herb Bright, a programmer at Westinghouse, recalls it as such, Curious, I opened the package and found that the deck was binary and that it just about filled the 2000 card box. There were no identifying marks and no instructions of any kind in or with the box or in the mail received that day, end quote. Fortran was already on the mind of most IBM users of the time. There had been talks, demos, published articles, and even manuals floating around for the past year and some change. So when the anonymous stack of cards arrived,

Bright and his co-workers figured it had to be the compiler. Over the course of that April afternoon, Bright and his co-workers loaded up the compiler into their 704, pulled out some example code they had worked up, did a little bit of debugging, and were able to get a fully compiled program up and running. This was one of the first times that Fortran was compiled by the general public, or at least IBM's general client base. And despite the bumbling on Big Blue's part, it all came together pretty well. I think this is a great example because it shows how easy Fortran was to get up and running. From the limited pre-release information on Fortran and a deck of unlabeled cards, Westinghouse was able to get off the ground with the new language in as little time as an afternoon.

It was fast to write, it was fast to debug, and the final product even ran pretty fast. Following the accidental launch, IBM started to ship more robust tapes of the compiler. It seems that once Fortran got into the wild, most existing resistance to high-level programming languages started to melt away. Part of this was thanks to IBM's clout. The company had put a lot of material on Fortran out leading up to its general release, and there was a good deal of hype around the product. And more importantly, Fortran lived up to all the hype. It delivered on every promise of performance and ease of use that IBM had made.

Quoting Backus one last time, quote, by the fall of 1958, there were some 60 installations with about 66 704s, and more than half of the machine instructions for those machines are being produced by Fortran. The first release of Fortran was clunky, and it was limited, and in the coming years it would be improved. Over time, it became foreshadowed by more advanced languages, but Fortran hit the stage at the exact right time with the exact right feature set. As the 50s gave way to the 60s, it became one of the de facto languages for computers, spreading beyond just the IBM 704. But importantly, perhaps most importantly, it made it possible for more people to program. perhaps most importantly, it made it possible for more people to program. As was Bacchus' goal from the beginning, and even Hopper's goal earlier than that,

there was finally a way for people who didn't want to deal with the bits and wires to use a computer. I think that just about does it for our dive into the origins of Fortran and the broader birth of programming languages. From early days, it was obvious that programming would need to change, and through some difficult trial and tribulations, it did. Thanks to visionaries like Grace Hopper, John Backus, and their countless colleagues and supporters, programming languages went from a dream to a very real reality. And once programmers got a taste, they couldn't get enough. Without that shift, the modern world may have turned out much less computerized. Grace Hopper didn't fall out of the scene after her A2 compiler. She would stay active in the computer industry for decades and decades to come. Her work eventually led to COBOL, another early and

very long-lived programming language. As for Fortran, it would go through a number of iterations inside IBM, but it wouldn't stay within Big Blue for long. In 1966, the American National Standards Institute convened a committee to form a standardized version of Fortran. This would turn into a semi-regular event, creating the standards for Fortran 66, 77, 90, and so on into the modern day. Compilers based on these standards would start showing up almost immediately, and it wouldn't be long before just about every computer under the sun had its own version of Fortran. But more than just the sundry versions of the language that appeared in the coming years and decades, the fact is these early innovations paved the way for more modern programming languages that make modern computers so useful. It set the stage for the modern programmers that make everything tick today.

Thanks for listening to Advent of Computing. I'll be back in two weeks time with a new episode about the making of the modern world. And hey, if you like the show, there's now quite a few ways you can support it. If you know someone else who would also like the show, then why not take a minute to share it with them? You can also rate and review me on Apple Podcasts. And if you want to be a super fan, then you can support the show through Advent of Computing merch or signing up as a patron on Patreon. Patrons get early access to episodes, polls for the direction of future shows, and other assorted perks. You can find links to everything on my website, adventofcomputing.com.

If you have any comments or suggestions for a future episode, then go ahead and shoot me a tweet. I'm at Advent of Computing on Twitter. And as always, have a great rest of your day.