Advent of Computing - Episode 101 - Origins of Ada

Episode Date: February 6, 2023

Ada is a fascinating language with a fascinating history. It was initially developed as part of a Department of Defence project. The plan was to create a standardized language for everyone inside the DoD. The results, well, they may just surprise you.   Selected Sources:   http://archive.adaic.com/pol-hist/history/holwg-93/holwg-93.htm - Ada at the HOLWG   https://dl.acm.org/doi/pdf/10.1145/956653.956654 - Rationale for the Design of Ada   http://iment.com/maida/computer/requirements/strawman.htm - Strawman

One of the main themes of my coverage of programming language history has always been this idea of the quote-unquote perfect programming language. Now, the sad truth of the matter is there can never be a perfect universal language. That's a fact, and I'm willing to fight to my grave to support it. You just can't have a universal tongue that does everything and does it well. You have to have specialization. That said, well, wouldn't it be really nice if there were only one language to learn? Just think about the benefits for a second. Every programmer in the world could read every other programmer's work. You could make collaboration a lot easier just by everyone sticking to the same language.

Compatibility wouldn't even be a subject of discussion anymore. One line of code from one project could very literally just be thrown into any other. Just a copy and paste job and boom, you're collaborating with any other programmer. It would also save a lot of time and money. One programmer could do the job of any programmer. No specialized training really required.

Hiring would be a cinch. A job listing would just say programmer. You wouldn't even have to specify Java or PHP, C++ or Fortran. Everything would be simplified, streamlined. It's a nice world to think about, but it's purely fictitious. However, the draw of this idea of a universal language, a perfect mother tongue, has excited many programmers. Some have even tried to make it a reality. So, let's suspend disbelief for a minute. How would one go about crafting one tongue to rule them all? Welcome back to Advent of Computing. I'm your host, Sean Haas, and this is episode 101, The Origins of Ada.

And let me just say, after passing the 100 mark, it really does feel like the show's entering a new era. But fear not, little will change. Today, we're delving into a pretty classic topic here on the podcast. That's the more strange side of programming. The language we're discussing today is MIL-STD-1815, or, to the sad majority of people who can't quote US military standards, ADA. Or is it pronounced ADA? I'm never entirely sure.

Anyway, we're looking at the odd development of a language that's still in use today. At least, it's some niche application. ADA is currently used in applications such as planes, trains, and spacecraft. I know, it's really close to that magical trifecta. The language has a very interesting blend of features. It supports multitasking, message passing between tasks and objects. Ada is also an explicitly real-time language, which makes it perfect for, well, planes, trains, and

spacecrafts. It could also probably handle an automobile pretty well. So far, this shouldn't sound too unique, too weird. This all makes sense within the Hopperian lens that I like to use on the show. Grace Hopper proposed that there should be many multiple languages for different niche applications. So, ADA, at least in the present day, seems to fall within that view. The history of ADA.

Well, that's where we get into the true weirdness. As the MIL-STD moniker suggests, ADA is actually specified in a military standard. It started life as a Department of Defense project. From there, things spiral out into many interesting trails. You see, ADA has hardware implementations. Or at least there's chips that were designed specifically to work well with this programming language. And you know me, I'm a sucker for anything that can blur that line between hardware and software. One of these chips is the MIL-STD-1750A. You know, good ol' 50A as I like

to call it. If you can't recall those numbers, then I can understand. I'll forgive you. This chip showed up way back when I ran an episode on the Jovial programming language. I also did a Patreon-exclusive episode on the processor itself. 1750A was a chip designed to run Jovial, Fortran, and Ada. That's a strange mix of applications right there. But the thread goes even deeper. In the middle of the 70s, Intel was trying to create the next great processor. They wanted a processor that would support object-oriented programming, a paradigm that can be tricky for some chips to handle. programming, a paradigm that can be tricky for some chips to handle. Their ultimate solution was a massive undertaking to create a higher-level processor. The chip, the IAPX432, had hardware

support for data types. You could even specify your own data types on the silicon level, which could be used to facilitate object-oriented programming. The 432 project was, to put it simply, a disaster. It drug on and on, and Intel started to fall behind their competition. As a stopgap, Intel threw together a team to make a tiny 16-bit processor. That chip was known as the 8086. It's a little footnote that eventually would become the default architecture for home computing. The 432 would be released in 1981 to almost no acclaim at all. Circling back a little, the whole point of the 432 project was to have a chip that paired well with an object-oriented language. A well-matched

chip-and-dip, if you will. So what language was Intel shooting for? Would it surprise you if the answer was also a military standard? Would it surprise you to learn that Intel wrote an entire operating system for the 432 in Ada? Well, be surprised. I never imagined that I'd have the chance to talk about a failed intel chip and a really niche military standard in the same episode, but here we are, I guess. Today, we'll be looking at how ADA was designed and developed. This will take us into a strange story of military contracts, obscure languages, and straw men. I'm also going to bring up some old ghosts from past episodes. We will need to address what object orientation actually means in the Ada context.

We'll also be looking at how a language can support multitasking. That came up with Forth, but Forth is kind of its own beast. I want to see how Ada compares to what we've already seen. And most of all, how would you make a processor that supports Ada better than just any old chips? What kind of tricks do you have to pull to do that? I think it's important to start with some background. It's only recently that computers have become a monoculture. The PC boom and the rise of the x86 architecture has been a big part of that. But there have been other forces pushing in that same direction. Portable software and operating systems like the ever-present C and Unix have had a somewhat

similar effect. Over the years, we've reached this point where computers are mostly compatible with one another. Architectural differences don't matter quite so much anymore. Let's wind back the hands of time. What happens when we reach 1975? Well, pain. Pain is really what happens to us. The digital landscape at this time was fractious. Unix was just starting to gain some traction, but only a few platforms and only a few places actually ran Unix. Maybe a good measure of this fractured nature can be seen in the ARPANET, the precursor

to the modern internet. The ARPANET spanned the entire United States and reached into many college campuses and research labs. I think that gives us a pretty quick and dirty cross-section of incompatibility. So let's just look at a map of ARPANET sites from June 1973. It shows how everything is wired up, the sites connected to the network, and which types of computers those sites are running. We can see a lot of PDP-10s and PDP-11s, which, believe it or not, are actually totally incompatible. They are unrelated hardware. incompatible. They are unrelated hardware. 11s could run Unix and deal with C, but 10s didn't have any one de facto operating system. Some ran TOPS10, others ran TWINIX, a few sites ran CTSS, ITS, and WAITS. All roughly incompatible with one another. And while Unix did pull together some PDP-11s, it wasn't the only

operating system for that platform. Far from it, in fact. Outside of PDP land, we see IBM 360s, a few BBN computers, a Nova or two, some Honeywell computers, and at least one Univac machine. What's important to note here is that brand names actually meant something at this point. It's not like saying a computer lab has some Dells and a few HPs. A data general Nova has very little in common with an IBM System 360. Each manufacturer had their own operating systems, and each operating system had its own pet programming languages.

On the surface, sure, that's annoying, but there should be a lowest common denominator here, right? I mean, IBM computers were big on Fortran, but there was also a Fortran compiler for data general machines. BASIC could run on at least quite a few computers at this point. Not everything was up to spec, but there was enough crossover that things should kind of work out, right? Well, that brings us back to the Hopperian viewpoint. You need niche languages. Fortran can't really do list comprehension, so programmers that dealt with a lot of lists

and arrays had to make their own tools. BASIC can't do hardware-level stuff, so oftentimes you'd resort to assembly language or roll your own in-house system. I could go down a list of languages developed for specific projects. When a programming task is big enough, you end up writing a lot of tools. And sometimes that does turn into developing your own language. This was especially true back in the day when things weren't as well established. This is kind of a corollary to the whole niche language thing. As new niches are found, new languages tend to spring up to fill them. Lisp is one easy example here. During the

late 1950s, programmers started digging into the idea of artificial intelligence. The extant tools were just not really up to snuff. They would not cut it. So we can follow our law for the episode. New tools were developed. One of the earliest entries was IPL, which was followed by the bizarre Fortran list processing language and eventually Lisp. Those are three distinct languages made by three different teams, all occupying the same space. Eventually, Lisp became the winner in this niche, but

each of these languages had already been developed. Human hours, money, and computational resources had been used up to create three distinct programming languages. Even once Lisp was ascendant, there was still a high level of diversity. Different dialects of Lisp appeared on different machines. Some research groups would implement pretty on-spec Lisp compilers. Others would throw in their own special sauce. Thus, even with a clear dominant language in this very particular niche, there was still a measure of diversity, or to put it another way, extra work. Something like Treat, a Lisp-like, it was developed with government funds, and it's totally incompatible with the earlier language.

Maybe you can already guess who's impacted the most. Maybe I've given away too many hints. The real losers here were the feds, specifically the Department of Defense and DARPA. One of the first to spot this particular problem was U.S. Air Force Colonel William Whitaker. In the 1960s, Whitaker was working for the Air Force Weapons Lab, which you can shorten down to awful. I kind of love that. That's when he discovered this frustrating trend. To quote from Whitaker's presentation at the ACM's History of Programming Languages II conference, quote, Over this period, software programs had gotten much larger and more expensive, but tools and support had not kept pace. With each new machine,

operating system, or compiler, it appeared that all the common, first-level tools had to be regenerated. I wrote various tools half a dozen times over the years and finally felt like giving up. The tools never got out of the first generation because one could not build with confidence or share with others who had different machines. End quote. The fractured digital landscape was becoming an issue. We've talked about software development quite a bit on this show. You could say it's something of a hobby of mine.

Here's something fun to think about. How many programming tools can be used for multiple languages? I think the only possibilities are text editors and maybe hex editors and low-level debuggers. You can't use the same compiler for Fortran and COBOL, for instance. You can use a generic symbolic debugger, since that only really cares about the final binary, but that actually leads to another custom tool. A symbolic debugger is nice because it tells you which symbols are at which memory locations. Instead of just saying that, you know, there's a number stored at some address, it can say that variable name test number has some value,

or that a certain instruction is part of some named function. To get that mapping from symbol to address, you need a specialized tool, so that's more custom stuff. Another fun set of considerations are libraries. Let's take C for example here. Out of the box, C can't print anything to the screen. The language can only really do math, logic statements, loops, and some weird pointer magic. You can write out all your own C code to print to the screen, but that's a bit of work and it requires you know a lot about the computer you're working with. It's traditional to use libraries to fill this gap. For C, you have

a big pile of so-called standard libraries. Just import them and away you go. But those libraries don't just spring from the aether. Someone had to sit down and solve all these little problems for you. In the case of printing to the screen, someone had to write hardware-dependent or operating system-dependent code. In other words, it's a chunk of code that can't be used on any other kind of computer or any other kind of operating system. So these libraries are needed to do many really basic tasks. But they require extra effort and are often platform-dependent. Thus, the niche becomes more complicated. This is all well and good if a language sees a lot of use.

C needs a good compiler. It also needs some nice libraries plus support for enhanced debugging features. C has been used intensively by probably millions of people for decades. So all that work has been a good investment. We've been able to reap dividends. But what about TREAT or IPL? to reap dividends. But what about TREAT? Or IPL? A comparable development effort was needed for those languages and their associated tools. But that work didn't really go as far. TREAT was used for a single sub-project in a larger project. IPL did see some use, but it was kind of second fiddle to Lisp. It never became super mainstream. There's nothing wrong with having a language for every day of the week,

so long as you're willing to pay the price. For the Department of Defense, that price was very tangible. In 1973, Whitaker moved from awful to the OSD, the Office of the Secretary of Defense. This pushed Whitaker into a better position to see the overall software issue, and maybe even resolve it. What he saw was pretty appalling. Recent reports showed that the Air Force alone spent upwards of $1.5 billion a year on software. I don't think we even need an inflation calculator for this one. That's a lot of scratch. Now, this wouldn't be a software spend in the sense that we may think about it today. The U.S. Air Force wasn't paying Microsoft for office licenses. This money would

have gone out to contractors who were writing or maintaining software used by the Air Force. The overall analysis of the spending project is confusing and it involves an entire alphabet's worth of federal organizations. The core problem that kept cropping up was something that Whitaker called the proliferation of programming languages, the fracturing that we've been talking about this episode. On the lowest level, this proliferation of programming languages, the fracturing that we've been talking about this episode. On the lowest level, this proliferation was occurring because of differing hardware and software. Go up another level and we reach the first stage of administrivia. In America, the Department of Defense is the organization that sits above all branches of our armed forces. fence is the organization that sits above all branches of our armed forces. This includes the Army, Air Force, Navy, and Marines. These services don't always work together, and that was especially

true in the digital realm. The Air Force was pursuing its own goals separate from the Navy, so they may have similar computer projects just being handled by different contractors. Each contractor has their preferred platform and language, and things just spiral out from there. This is a situation where economies of scale should be leveraged, but no one was really doing that. So billions of dollars were being thrown out developing all these languages and tools that would only be used for single projects. How would one go about reducing all this overhead? I'm hoping that I've definitely guided you towards an answer. What if federal agencies and service branches could just work together, you know,

iron out their differences? What if they could all agree to some kind of gasp standard? I know, I'm clutching my pearls at the thought. It would be pretty hard to do that for, well, hardware. An attack helicopter's silicon has really a totally different task to do than a supercomputer. But that does leave something of an opening. Software could, in theory, be standardized. The proliferation problem could be solved, and a lot of our tax dollars could be saved if the DoD and its underlings all just used one language. Finding the one language to rule them all, that would prove to be quite the uphill battle. Whitaker and his colleagues would grind through a series of working groups and conferences before plans took shape.

Everything, of course, is filled with three-letter names. By 1975, we start to see something concrete. The overarching project was called the DODHOL, the High Order Language. That's what would be used when discussing the entire project, but within the project, there are a pile of other codenames. For our purposes, I want to focus on the actual standards, the concrete requirements for this single language. At this stage, the DoD was still looking for a suitable language. The hope was that there was already a perfect language floating around just waiting to be polished up and adopted. The first draft standard was called Strawman, and this is where we start

getting into the nitty gritty. First off, the project quickly gave up on the single language goal for the entire DoD. Instead, they were shooting for three. COBOL, FORTRAN, and the ethereal HOL. This isn't really a huge deal, I just think it's funny that even at this point, no one was able to migrate away from COBOL or FORTRAN. Those languages just latch on and never leave. So what does the Strawman spec do to address this? Well, in short, everything. The name here is a bit misleading. I went into this assuming that the DoD's spec would just be

a list of capabilities, like it should be able to solve a matrix in under 10 seconds, or it has to be able to connect to an impact printer. But oh boy, was I wrong. Strawman is a shockingly fine-grained proposal. It goes through every aspect of a language and gives a very clear requirement for all of those aspects. Strawman specifies everything from data types to scope to specific arithmetic operations. Let me give you an example.

Here's a subsection on comments. Quote, 1.f.5. Comments. End of line will be the terminator for a comment. The start of a comment will be designated by a language-specified single character. All language-specified characters may be included within a comment. End quote. To say what you will about the actual details, this is an impressive level of detail.

Not only should the new DoD language support comments, but the comment character also has to be the same as an end-of-statement character. It also has to be a single character. That's a lot more specific than just saying, yeah, we should have comments. I'm using this one example here because of how specific strawman really is. And while this stuff is interesting, there are some more impactful details to pay attention to. Here's a quick section from the source language subsection. Allow me to share these points. Quote-level aspect of the language will be formally specified.

None will be left to the translator, implementer, operating system, or object machine. The language will not reveal minor differences in computer architecture. Machine-dependent code cannot appear inserted inline in source language programs. The language will not contain special features for rare cases. End quote. Do you get the same feeling that I do from this? Because to me, this feels like the DoD was going for portable code. They wanted a language that could be used on any platform.

That makes good sense for the environment the DoD was facing. They may not be able to get all services to use the same hardware, but they could offer a common language that worked across every platform. But for this to work, though, there had to be a very rigid spec. Every aspect had to be formally defined. This really seems like the right way to go for this type of project. Just to quickly hit on the actual details of Strawman, we're looking at a statically typed language.

That means each variable has a defined type of data it stores. The spec also calls for structures, as in user-definable variable types. This allows programmers to, say, set up a special variable that's composed of two numbers and a string. We're also looking at a language with arrays, both static and dynamic, which means memory management is a must. Something to note, at least in this early phase, is that I think C could have actually fit most of Strawman's requirements. It has support for most of the data types the DoD wanted. Structures, platform independence, plus a slew of other attractive features. The problem here is partly one of timing, and I think this brings us to an interesting juncture.

You see, C doesn't really hit its stride until the late 1970s. KNRC, the definitive manual on the language, isn't published until 1978. Language wasn't super ready yet. Apparently, Whitaker did even reach out to Bell, but the lab said that C shouldn't be considered. A brave choice in the face of a nice DoD contract. So what did the language environment look like when Strawman was written? The most relevant languages here would be COBOL, FORTRAN, LISP, ALGOL, PL1, PESCAL, and SIMULA. I know, that's a pile of jargon there, so let me tease some stuff out. We've already hit on the C and F words, so

we can discount that. Those are just everywhere in this period. We can also rule out LISP, since, well, it's kind of its own thing. Strawman required that the language be clear and easy to learn, and that's not really Lisp's deal. Then we get to the rest of the pack. PL1, Pascal, and Simula, which are all based on Algol. As such, I'm gonna pull a shortcut. Instead of hitting each language separately, let's just go to the source and discuss Algal. By the time Whitaker and his colleagues were drafting Strawman, Algal was a well-established standard. The most used version was codified in

1968, so we are looking at a stable and standardized programming language. It was designed to be portable, statically typed, and had arrays and structures. On the surface, that looks like a sure thing, but there was an issue. As Whitaker explained in a 1993 paper on the HOL Working Group, quote, There were other common language meta-requirements. For example, the language must be an application user language. This went against certain academic concepts of mathematically minimalistic formulation, like ALGOL 68.

ALGOL was a nice language. It had a reasonable syntax and it had cool data types, but it was already specialized. ALGOL had been developed as this theory-first type of language, very similar to LISP in that regard. The whole point with ALGOL was to give a standard language for programmers and mathematicians to use. This led to the language itself, at least as written, being a little too narrow in scope for the DoD. That said, there were some good ideas here. It was decided that any language that would fit the HOL standard would need to be ALGOL-like. As for why PL1, Simula, or Pascal weren't used, As for why PL1, Simula, or Pascal weren't used, well, I'm not entirely sure.

We've hit the end of the trail. Whitaker has a whole lot written about the selection process, and there's a whole lot of sourcing on this phase of development, but it's spread out. It's not super fine-grained about specific choices. spread out, it's not super fine-grained about specific choices. My gut feeling here, and this is total speculation, is that the DoD really wanted to have full control over their fancy new language. Between that desire and the spec, no existing language would do. Something new was required. And thus, we arrive at what I think is the more interesting part of the whole HOL project. You may assume we're approaching a language designed by a committee, but that's actually not correct. I also fell for this assumption myself. The DoD avoided this

pitfall, which I think would lead to a better language. But before I get too ahead of myself, I should probably take a step back. If you want to scare a programmer, there are a few tricks. One of them is to utter the evil incantation, design by committee. This is a process by which a group of people compromise on a single design for a project. by which a group of people compromise on a single design for a project. In theory, this could be a good thing. You have multiple viewpoints, multiple areas of expertise, all working towards the same goal. In practice, however, this rarely goes well.

A bad committee structure can lead to a bad product. It robs a project of a certain cohesiveness. This can be especially bad if the committee is large or has a change in membership. How do you deal with a new voice that doesn't know what's been happening, or the loss of a major contributor? What you get, overall, is a nightmare. These projects are hard to handle and can go on forever. That said, there are benefits to this approach. It does allow for more inputs from more people, and in some cases, can help a large organization come to a collaborative result. It helps you build a consensus. The DoD was able to use parts of this committee approach and then pull a slick save at the end. The spec was designed by a committee, at least in a manner of speaking. Strawman originated within the DoD and was then

iterated with feedback from other parties. Once the first spec was done, it was passed around to help create the next spec. From Whitaker again, quote, There were mixed reviews. Some said it was too specific, others that it was too vague, so we knew we were on the right trail. The input and comments received by the HOLWG were codified and merged into a more complete but still tentative set of language requirements. This document was entitled Wooden Man. The iterative process continued for a number of years. Wooden Man became Tin Man, which became Iron Man, which became Steel Man. Input came from within the DoD, branches of the US military, academia, industry, really

anywhere that Whitaker and his cronies could reach. This allowed them to build up a really solid specification, even though it took a while. This takes us to the cool part. The next stage was to go out and find a contractor. We don't get a language designed by a committee. Instead, we have the DoD creating this very exacting spec, then handing it off to someone else. The department went through a pretty normal bid process here. They put out a call for bids and waited. According to Whitaker, they got a fantastic response. Quote, The quality of these bids was exceptional. I have evaluated thousands in my career, and these had the highest quality, as a group of any that I have experienced. In fact, I was approached by several well-known

firms that told me that in the normal course of business, they would have bid, but that this procurement was so important that others could do a better job. I have never, before or after, heard of such a recommendation for a government program. End quote. It's interesting to note that we see the Bell Labs approach show up again. Earlier, Bell had asked that C not be considered because it wouldn't have lived up to the spec. It wasn't a fully formed language yet, and it didn't have some of the more advanced features that the DoD wanted. Some prospective contractors chose not to offer language because they didn't feel up to the task. They wouldn't be the best fit. From this pool of bids, the DoD chose four to take to the next phase.

Those contractors would then develop a full proposal to pitch. This competitive bid process ensured that the actual language would be designed in a pretty conventional way. It wasn't a committee job, it turned out that the DOD's HOL would be built by a pretty small team of programmers, but once again, I'm getting ahead of myself. Who were these poor contractors that had to wrestle with Seal Man? In order to fit in the whole spook show thing going on at the DoD, each of these proposed languages had a color-coded name. In one corner, we have the Red Team at Intermetrix Inc. They had most recently developed HAL-S, the High Order Assembly Language slash Shuttle. This was used by NASA for parts of the Space Shuttle program. I think that speaks volumes as to Intermetrics chops and connections.

Opposite them was the blue team at SoftTech, which was a company that existed. It seems their biggest claim to fame has to do with CAD and management software. Opposite again was SRI International running Team Yellow. I think this side needs no introduction. The Stanford Research Institute is an organization loosely connected with Stanford the University. SRI acts as an umbrella organization for a lot of different labs. Engelbart, for instance, was part of SRI acts as an umbrella organization for a lot of different labs Engelbart, for instance, was part of SRI So we have another contractor that's well-connected and has a strong background

And finally, we have the green team at CII Honeywell Bull with Gene Iqbaya What's notable about CII Honeywell Bull, or CIIHB, or Bull Group There isn't a great way to shorten this, is that it's a foreign company. They're based out of France, not the US of A. So if we want to punch up the screenplay here, we could call CIIHB the Dark Horse candidate. They were the underdogs from the start. How could they convince the DOD to accept their proposal? Well, as it turns out, quite easily, actually. Whitaker makes it very clear that he wanted this HOL thing done right the first time. There were no deadlines, and there were very few restrictions. There was also plenty of funding. This was a solution to a billion-plus dollar problem. It had to be a good fix.

As early as Strawman, the DoD was soliciting help from European researchers. The whole project may have been aimed at the US military, but international collaboration was part of the plan from the beginning. As far as proposals went, everything turned out to be a shade of Pascal, which brings us to another bit of background. At the time, Pascal was a bit of a big deal. It was relatively new, first hitting keyboards in 1970. It was also based off Algol, so it shares a mother tongue with C and many other languages. Pascal also met a lot of the requirements put forth in Steelman,

so it made for an easy base to start with. The creator of Pascal, one Miklaus Wirth, even consulted for the DoD during the development of Steelman. So there's a lineage forming here. Whatever the DoD went with, they were tying themselves to Pascal and Algol. Honeywell Bull and Intermetrics made it to the second phase of the bidding process, where they were directed to continue development of their languages. At this point, full specifications for both green and red were written, as well as what Whitaker called, quote-unquote, preliminary translators. I'm assuming these were just first attempts at some compilers, but the language is left vague. I think that was done in an effort to allow wiggle room in design. Finally, and most importantly, each team was given

a set of problems to solve in their new languages. Now, I keep being blown away by how, frankly, this entire process was very well thought out. Going into this, I assumed that any DoD language would be something of a hack job. When I hear about a language built to a big fancy standard, well, I get concerned. Algol is a famous case study in this regard. It was initially so standardized, so platform-independent, that it didn't even have a way to print text. COBOL is another. It has all kinds of problems and exists in this space separate from normal computer science. But here we have the DoD actively trying to do the right thing in the right ways for the right reasons.

This is something that Whitaker stresses again and again in his History of Programming Languages presentation. The whole HOL project was planned to take as long as it needed, to spend as much as it needed, and to land on a long-term solution. That meant that, among other things, there had to be working examples of programs in each proposed language. This would give the DoD and, really, everyone involved in the overall project a better taste of each language. A programming language can look good on paper, but you really need to see it in action to judge it. You have to use the thing. What judgment was passed? Well, simple. The Greens had it. There's a whole lot of visibility into this phase of the bid process. We actually have a full reference manual for the RED language,

called RED-L internally. I don't want to go down that route today since it's kind of a tangent. It's there if you want to dive deep into things, though. From what I've seen, RED was described as a more conservative language, something more in line with what a military contractor might dream up. Green, on the other hand, was more academically minded. Mary Van Dusen, one of the many, many people involved with the HOL project, also points out something kind of funny. Red and blue were both described in very verbose and exacting terms. I'm paraphrasing here, but she describes the dock for red explaining how a Boolean was implemented all the way down to the silicon. Whereas Green, well, to quote,

It was said that Green's first design decision was the length of the book they would create. Where Blue had spent pages on the real meaning of Boolean, Green said there's true and false. Period. Green demanded that you trust the designers when they said what the language could do, even if the details weren't there to prove it. End quote. Van Dusen also calls this politically savvy.

I'd say it's playing to an audience. Programmers tend to like clarity over accuracy. I know I don't want to wade through pages of documentation when I'm just looking for a sentence. It's nice to have the whole tome, but you can get to that later. You usually need two pages out of the entire volume. This is also where the name and the language finally meet. The new language was renamed from Green to Ada. Apparently, the name had been chosen well before the final phases of the bidding process. It was meant as a tribute to Augusta Ada King, the Countess of Lovelace.

She's more commonly known as Ada Lovelace, the first computer programmer. Caveats aside, this was perhaps a fitting name for the ambitious new language. So what kind of language are we actually dealing with here? This... Well, this takes us to a bit of a rabbit hole that I actually do want to pursue at least a little. The chief designer of Green, aka Ada, was Gene Ikbaya. He was a programmer at Honeywell Bull. By the time the DoD bid process started, he already had experience in language development.

But here's the thing. The language he worked on previously was called LIS, and it's one of those footnotes in computer history that appears to exist, and that's about it. This was a low-ish level language, I think. It was designed as a system implementation language, so it's in the same broad class as C. You can dig up some code examples, and it looks a lot like Pascal, which it was based off of. It has colon equals for assignments and begin slash end blocks. That's about as deep as my analysis of Pascal goes. But the actual paper that describes LIS seems to be missing from the internet.

It's called the System Implementation Language LIS. That's the name of this very important paper. It's frequently cited, and it is not available anywhere online. What we do have, however, is a pretty weird paper trail. Remember how I pointed out the whole translator thing? Well, it turns out the wording here was actually pretty important. LIS was meant to be used for operating systems. Some of the early writing that describes the language explains that Iqbaya was trying to make this high-level tool that could handle most operating system tasks. Basically, everything but the super low-level stuff.

Once again, this sounds a lot like C. There's even a compiler for LIS, although I have no idea what that was written in. Here's where we get to go off the rails a bit. Iqbaya had already developed and implemented LIS by 1978. So when Steelman comes along, LIS is ready to go. He used LIS as the basis for green. From what I can see, Iqbaya basically adapted his earlier language to fit the steelman standard. But, you know, the standard was wide-sweeping. It didn't just cover the language itself, but also its tools. One of these stipulations was that the fabled language had to be self-hosting. That is to say, that the compiler for Ada must be written in Ada itself.

This is a classic chicken-and-egg kind of problem. You want to self-host because it makes for more portable code. Plus, it's just cool. But how do you write a compiler in Ada if you don't have an Ada compiler? The solution to this barnyard issue is called bootstrapping. Historically, there have been a number of approaches to this process. Sometimes you just write the first compiler in assembly language as a quick and dirty job. But Iqbaya chose to take a special route. He started by defining this thing called AdaZero, and I do apologize for all the annoying and barely different names this episode, but we just have to live with it.

AdaZero was a strict subset of Ada, basically the minimal amount of features needed for writing a compiler. It's missing fancier features like tasking, which we will get to eventually. So that's nice and all, we have a simplified version of this big new language. How does that help? Well, Ada0 is easier to write a compiler for, there's just less stuff in it. That's the short answer. Once you have an Ada 0 compiler in Ada 0, you can then use that to write a fully-flagged Ada compiler in Ada 0, and then bootstrap all the way up to an Ada compiler in Ada itself. That's the path forward, as labyrinthian as it sounds. That reduces the overall workload for bootstrapping. But it still leaves us with a crucial link.

The initial AdaZero compiler still has to be written. So here's the next trick. What if you didn't have to write a new compiler at all? What if you could use an existing compiler? Iqbaya already had a nice LIS compiler just sitting around on a hard disk somewhere. All he needed was a way to use it. So what ends up happening is instead of writing a new compiler for AdaZero from scratch, Iqbaya wrote a translator that turns this simplified Ada code into LIS. The output can then be compiled with the existing LIS compiler. So let's take a look at the full

bootstrapping route, since I think it's kind of wild. First, we have the AdaZero compiler written in AdaZero. That's ran through the LIS to AdaZero translator, which outputs an AdaZero compiler written in LIS. That program is then compiled normally with the existing compiler that Iqbaya already wrote. That gives us a functional Ada0 compiler. From there, it's possible to write a full Ada compiler in Ada0 and compile it. That takes us from zero to full self-hosting in just a few steps. But let's get back to the main part. What was LIS actually like? Well, this paper on the LIS Ada Translator gives us a good idea. To start with, this earlier language fits into the Pascal side of the Algol family tree.

It's a high-level language with complex syntax, but it's nothing like C. At least, it doesn't look like C. We don't have curly brackets and closing blocks of code. Instead, we have begin and end statements. This is a part of this earlier ALGOL lineage, and it's kind of a marker of hearkening to an earlier age of programming. LIS was designed to be programmed in EBCDIC. Another mouthful. That's an older character encoding scheme that originated at IBM and was used for, drumroll please, punch cards. This was a pretty limited character set.

Notably, it doesn't include a lot of special punctuation. So curly braces are out just for one. A lot of these older languages stuck with words over symbols because of this. LIS isn't part of this antiquated class. It was made in the 70s, but its lineage draws from languages that were developed much earlier. This makes LIS look a bit dated, at least to my eyes. We also get the usual set of variable types. We get enumerations and structure-like things.

This part is basically what you'd expect if you've used anything like C, because, once again, we're dealing with cousins here. LIS is also modular, meaning that chunks of code and data can be broken into separate units. There's also some caveats with how scoping and control structures work, but everything very roughly looks somewhat normal. The modules are the only notable exception. The modules are the only notable exception. This Ada 0 to LIS translation paper is also where something really started to click for me. Whittaker talks a lot about how Ada can't be a superset of Pascal.

It has to be a new language in the spirit of Pascal. Well, I think I'm starting to get what he meant by that. Iqbaya didn't just add features to LIS to arrive at Ada. He changed how certain parts of his earlier language worked. One example is typing. LIS just has different data types than Ada. has different data types than Ada. LIS offers single-dimension static arrays, but Ada can do dynamic arrays of any dimensions. Ada is strongly typed, meaning an integer is declared as an integer and can only be an integer. I'm not super clear on LIS's typing system, but Iqbaya assures us that it's not that strong. There's a lot written about how datatypes in Ada have to be kind of coerced to work with LIS during translation. So after all this bidding and all this bootstrapping coolness, we're left with Ada. We've talked a lot about the development and circumstances around this language, but

haven't really looked at the language itself yet. So let's fix that. What exactly is Ada like? How does it live up to Steelman? During the final stages of the Ada project, Ikbia and his colleagues wrote a little number called Rationale for the Design of the Ada Programming Language. You know how one of the benefits of green was its terse documentation? Well, this text makes up for that. It's over 200 pages and it goes into the full nitty-gritty of why and how Ada is constructed. I really do mean every word here. The book even has a section that covers the choice of character set. It's ASCII, by the way, so we do get all the characters of our dreams.

I'm going to do my best to cover my impression of this work, since, you know, it's a lot. It will eat you and your whole family. First of all, Ada is a very verbose language. It's not on the level of Kobold, but it's definitely in a similar ballpark. The entire language uses the ASCII character set, so it could have gone the curly brack route, but it just doesn't. We get begin and end statements. Control structures like if have to be ended with an end if, for example. Once again,

this is hearkening back to an earlier lineage. We also see this verbosity when it comes to variables. I don't want to spend a whole lot of time on typing since it's complicated and I don't think it adds to the overall conversation, but check this out. Ada lets you declare your own variable types, some of which are called subtypes. They essentially give the programmer a way to put restrictions on a variable. One common example is a definition for a letter subtype. That's written something like, Subtype letter is character range A dot dot Z semicolon. It's a neat little feature that plays into some of Ada's strong suits, but do note that we're using very few special characters here. Each line ends in a semicolon, but that's about as exotic as it gets.

Another interesting point here is, well, these whole type restriction things. Ada was designed as a safe language. By that, I mean it had inbuilt features to prevent certain types of mistakes and bugs. Restrictions were one way of doing that. Let's say you had a function that asks for a letter as an argument. If you tried to pass it a number, then something bad could happen. That's easy enough to look out for, though. Just make sure the function only accepts characters. Subtypes let you go a step further.

What if the function wants a normal, typable letter, but you pass it an exclamation mark. That could also lead to bad behavior. Making a letter subtype that has to be A through Z gives you a way to prevent this kind of issue. This type of safety was built into Ada for a good reason. The language was meant for military and federal applications. It's one thing if you have a dumb bug in a game. It's a totally different story if that same bug shows up in code that runs an ICBM, or a fighter jet, or maybe a train. Slightly different stakes there, you know? Ada has a whole host of features designed to minimize bugs and deal with errors.

One other example are exceptions, which let you specify what to do in case of an error occurring. Now, there is something I do want to blow a bit more hot air about. Those are modules. To me, this is what makes Ada an interesting and distinct language. Plus, it's very in line with the whole idea of big mission-critical software. When it comes to larger codebases, you want to be able to reuse past work, or the work that other contractors have already done. This does bring us full circle back to the point of Ada and the DoD's HOL project. A standard language

is a good step, and it's even better if that language helps you minimize your work. Modules are how Ada implements this plan. So here's how they function. You can break a program up into smaller units, the modules. Each module can contain data as well as active code, so variables and functions. The neat part is that a module can either be used as raw source code or pre-compiled. That may sound like a small aside, but it's a big deal in this context. Let's say you're a contractor working for the US Army, and you write this slick program for interfacing with a radar dish. It's fast, it's compact, and it has some very fancy intellectual property tucked inside. You're then approached by another contractor who works for the Navy. They also want to interface

with the magic dish, but you don't want to fork over your code. Maybe you want to keep a monopoly on some of your tricks, or maybe there are some actual trade secrets that you can't want to fork over your code. Maybe you want to keep a monopoly on some of your tricks, or maybe there are some actual trade secrets that you can't share with them. With Ada, that's not an issue. You can give the third party a pre-compiled version of your module. It won't be as portable as source code, but it will run just fine and will keep your secrets safe. Modules also enable flexibility in development strategies. This is the less glamorous side of programming, but an important aspect nonetheless. Compiling code actually does take time, that was especially true on older computers.

If you have modules sitting around as pre-compiled binaries, then you're all set to use them. You can also prepare modules way ahead of time, so you get some scheduling flexibility back. It's a nice way to break a big project down into smaller tasks, little projects that can be tackled more easily. Ada also implements modules in a pretty smart way. Each module can offer up publicly accessible data and code, things that any program that uses the module can access. You can also keep some parts of the module private, walling off certain variables and functions. Why would you want to do this? One reason would be encapsulation. You don't want other modules mucking around inside your code. That can lead to some pretty strange bugs. One common example would be a set of internal variables. Your module might assume that these variables are always set in a certain way, always controlled. We may be

talking about something like a simple flag that tells the module a task's completed. You really don't want some external program messing with that kind of flag. So Ada lets you hide that kind of data within your module. Outside code can still use that module, it's just that the gates aren't swung all the way open. There is a lot more to say here. In fact, there's a lot more to Ada than I initially thought. So, well... Thus concludes part one of my coverage of Ada. This has turned into a surprise series for both you and myself. I've basically just hit a point where there's a lot more about Ada I want to discuss, but I need to take some more time to

do it properly. This episode is mainly focused on the early history and development of the language. What's left are four big things I need to cover. First off is tasking. This is kind of what pushed me over the edge. Ada supports multitasking and signaling between processes. That's a huge topic. I got to the point where I basically read up all the sourcing I need to discuss that, but I need more space and I need a little more time to put things together. I haven't done one of these surprise spinoffs before, but I think there's enough justification in tasking alone. Second are objects. Now, initially Ada doesn't support object-oriented programming. Officially, the language supports OOP by the 90s. That said, reading through this early documentation,

I get a lot of glimpses of objects. Ada comes out the gate with certain features that are in line with later object-oriented languages. That's really interesting to me and something that I need to address. Points 3 and 4 overlap a bit, so I'm smushing them together. There are applications of Ada and fancy hardware. The hardware piece was my initial draw to cover Ada. I've already covered some of the history of the IAPX432 during my Intel series, and 1750A has its own bonus episode on Patreon. Those are both fascinating chips, and I want to talk about them with a little more detail. I think the best way to do that will be to look at some of the applications of Ada on that hardware. But as you can tell, that's another huge swath of work. So look at that.

We already have a game plan for next episode. I'll be back next week with part two of Ada. Until then, thanks for listening to Advent of Computing. If you like the podcast, please take a minute to share it with a friend or review it on Apple Podcasts. If you want to support the show directly, you can become a patron on Patreon or buy merch for Advent of Computing. Patrons get bonus episodes, polls for the direction of the show, and early access to everything I do. There's actually a poll up right now for the next bonus episode, so if you want to

get in on that, you can head over to my website, adventofcomputing.com, and find links to everything. If you have any comments or suggestions for a future episode, then go ahead and reach out to me on Twitter. I'm at Advent of Comp. That's usually the easiest way to reach me. And as always, have a great rest of your day.