Advent of Computing - Episode 103 - The Text Interface

Episode Date: March 6, 2023

This episode I attempt to find the first interactive computer text interface. All I can say is, well, it's a journey.   Selected Sources:   https://sci-hub.se/10.2307/3917015 - Early article on Stibitz's CNC Model I   https://archive.org/details/fortranprimer0000orga/page/103/mode/1up?view=theater - Primer on the FORTRAN Monitor System   https://kyber.io/rawvids/LISP_I_Programmers_Manual_LISP_I_Programmers_Manual.pdf - LISP I manual

There are certain traps we can encounter when discussing history. I don't necessarily mean bad sources or easy misinterpretations. Here, I'm more talking about shiny objects that draw our attention. Certain events and certain figures just have a magnetic draw to them. Some topics are just more exciting to cover, or at least they seem that way on the surface. are just more exciting to cover, or at least they seem that way on the surface. This can become a problem when we're dealing with the existing status quo. The graphical user interface is a really easy example of a shiny object. It's cool. It was revolutionary, and we still use it today. It is very much our digital status quo.

use it today. It is very much our digital status quo. So who wouldn't want to research the origins of the GUI? It raised us out of older interfaces and really threw computing into the future. These big events even have their own mythology around them. With the GUI, we have the mother of all demos, the Xerox Alto, and the Macintosh. We get larger-than-life figures to go along with this too, like Doug Engelbart, Alan Kay, and Steve Jobs. Of course you'd want to learn more. Now, I'm not saying that we should avoid shiny objects altogether. More that their sparkle can cause us to miss the forest for the trees. It's exciting to talk about how the status quo came to be. But what about the previous status quo? When the GUI

arrived, it was replacing older, less friendly interfaces. It was a new alternative to the text interface. If the GUI arrived without a dragon to slay, well, that wouldn't make for a very good founding myth. Hopefully, I've steered you towards a deeper question here. For Engelbart to come in and shake up the established norms, those norms, well, they would have had to be established in the first place. those norms, well, they would have had to be established in the first place. If you're replacing something, then that something must have come from somewhere, right? So where do text interfaces come from?

Surely they must have their own founding myth. Was there an even older dragon to slay? Did knights even exist in those bygone ages? Welcome back to Advent of Computing. I'm your host, Sean Haas, and this is episode 103, The Text Interface. Today, we're looking for a missing event, or rather, we're going on a journey that may or may not have a concrete destination. This episode is a dive into the origins of the computer text interface. Tracking down the exact event is, well, it's been a bit of a slippery slope for me. This is one of those episodes where we need a measuring stick to keep everything lined up. So allow me to introduce REPL. It stands for Read, Eval, Print, Loop.

This is a term that's been used to describe Lisp's interactive interface for quite a long time. It works exactly how it sounds. First, the program waits for you to type something in it, reads something off the keyboard interface. Then the computer evaluates what it read. Once that's over, it prints out whatever it's evaluated. That output goes to the same interface the user's sitting at. Then, well, it just loops and does it all again. In the context of Lisp, eval has a special meaning, but I'm going to fudge it a little bit. I'm just going to steal and misappropriate REPL

and use it as our historical test for text interfaces. What we're looking for is a program that takes input from the user, does something, spits out a result, and then loops. There's also the hidden implication that it's all done via a combined text interface. The user has to be sitting at something similar to a terminal, or a keyboard and a screen, or maybe a little dashboard with an LCD and a keypad. I'm not going to be super picky. So the question is, of course, when did this start? Where did the idea of an interactive text interface come from? There are a few traditional stories. If we're talking strict REPL here, then of course it has to be Lisp. An interactive version

of Lisp was written for the PDP-1 in 1964. That's the most conservative option. Another popular guess has to do with timesharing. The whole point of timesharing was to split up an interactive computer session for multiple users. But that had to be replacing something itself, right? There had to be non-timesharing interactive systems. Right? If that's the case, then we could be looking as far back as the 1950s. Were machines in that era even powerful enough to do text processing?

I'm hoping I'm laying down the right vibe here. There's no agreed-upon or no commonly agreed-upon point for the birth of the text interface. So unlike with the GUI, where we have pretty solid, big, inciting events with well-documented lead-up, for the text interface, usually it just kind of exists in the historical record. So we're going to be kind of going into the unknown here. I'm hoping this can serve as a journey of discovery for all of us, so strap in for a bit of a stream of consciousness-style episode. Let's start with the classic switcheroo. To talk about what text interfaces are, we need to look at what they are not. That is, what came before nice interactive shell sessions?

The short answer is batch processing, but that really doesn't give us the actual interface that programmers were using. So let's work up a subsidiary question here. How was data getting into computers in the first place? In the early days, there were two ubiquitous options. Punch cards and paper tape. Punch cards, I think, need no introduction. They were those funny slips of cardstock covered in tiny rectangular holes, or occasionally circular holes in some jurisdictions. Paper tape is a very similar medium. It's just a long, rolled-up strip of paper with holes punched in it.

Either way you cut it, we're looking at very physical encoding schemes. Paper tape is actually older than the venerable punch card, if you can believe it. Rolls of paper were used for handling data as far back as the 1800s. Now, note that I don't say data storage. That gets a little complicated. At this point, paper tape was being used in telegraphy. Fancy printing telegraphs would receive a message and then print it out on paper tape. You would either get actual printed text, punched holes that encoded text, or something akin to Morse code. This wasn't really a reusable form of data per se, just a way to pass along and store a message temporarily.

Eventually, paper tape was picked up for use with computers. early. Eventually, paper tape was picked up for use with computers, and by eventually I really mean as soon as the first computers started operating in earnest. By 1944, the Harvard Mark 1 was reading code and data from punched paper tape. In this case, the tape held data as a series of punched holes. The Mark 1 had a pretty unique encoding setup, so it used its own tools to make and read these tapes, but there were extant standards that were used by a whole lot of machinery. The printing telegraph was developed in 1944, which used a piano-like keyboard for text input. The user was able to play out data, which was punched onto tape for later transmission. By the end of the century, we get the teleprinter.

These newer devices had full-stroke QWERTY keyboards, and they automatically translate a typed character into a series of holes on a paper tape. This design would carry over into teletype terminals. So when it comes to creating paper tape during the digital age, well, it was really as simple as using a normal typewriter. Punch cards followed a similar type of trajectory, from specialized machines to more general-purpose keyboard monstrosities. Some of the first cards were punched using Hollerith's keyboard. This was a pretty dumb device. Essentially, it had a palette of possible options on one side and

held a blank card on the other. The operator would move and depress a stylus to select an option. That stylus was connected to a swinging arm that, when depressed, would push and punch down into the waiting card. Very manual, but workable for the time period. There are a number of intervening methods, but by the late 1940s, we get automatic key punches. These are the punch card analog of the teletype. Users could just sit down at a typewriter and hammer out text on a pretty normal looking keyboard. The machine took care of encoding, moving around cards, and even ejecting filled cards. It was all very civilized. Those are the two big non-interactive input methods that we have to consider. In both cases, we get keyboard interfaces that create an intermediate product, either tape or cards. That media is then fed into a computer. That makes

both these methods pretty indirect. A keypunch isn't wired directly into a computer. So to actually, say, write a program in Fortran, you first have to make your deck of cards. write a program in Fortran, you first have to make your deck of cards. Then those cards will be taken from your keypunch over to the computer's punchcard reader. You have to physically get up and move from one device to another. Depending on the office layout, you might even have to go to another room or another building. I'm stressing this last part because the indirectness here is really important. When I say that most early computers were non-interactive, well, this is what I mean. There were also, in theory, all these administrative layers between users and the computer, but let's disregard that for a few minutes at least.

We can see this non-interactivity just by virtue of how these machines were designed. You didn't get to sit down and punch data directly into the machine, at least not for any substantial tasks. There were blinking lights and switches and sometimes keyed interfaces, but that was more for diagnostic work or, in some cases, small numeric inputs. So what about outputs? Well, that also falls into the realm of non-interactivity. The best case was a printed output. It was common for mainframes to have their own printers, so a program could output human-readable text. But that was only one of many options. Depending on your hardware, outputs might be sent to a card punch or a tape puncher. So you're left with encoded data, either on punch cards or paper tape.

That's not human-readable. Once again, we're looking at indirectness and a lack of interactivity. One of the reasons for this arrangement came down to hardware limitations. Early computers were single-tasking machines. They were built to do one thing at a time. This made managing digital resources a little tricky. The main approach, one of the fun administrative layers that I mentioned, was batch processing. In this regime, a programmer would submit a job to be executed. That's your deck of punched cards or reel of paper tape. That job would be scheduled, some digital clerics would

shuffle your cards into the machine, and then you'd be able to pick up the outputs at some later date. This approach allowed a single computer to be shared between multiple users, as long as those users had some patience. And the weird thing, at least to me, is programmers in this era might never see the computer they were working on, or if they did, it would only be furtive glances. Now, the other reason to fall back on batch processing came down to the cost of machines. In the 50s or 60s, a computer was so expensive that a university or a research outfit might only have one machine. They were also relatively fragile devices, so you want to minimize the number of people in direct contact with the computer. All these

reasons made interactivity uncommon during this early period. We can use this background to start focusing our search for interactivity. Here's a few things to look for, a few possible hints at leads. First, we might be looking at a computer that had a small user base, such as an experimental machine. Second is a computer with some type of direct input. And third is multitasking, either in hardware or software. Now, the first point is kind of my catch-all here. Research labs are, most often than not, ahead of the curve when it comes to technology. You know, that's kind of the whole point. It would be dumb if a research lab was five years behind the times.

If you have a space with new tech in it, plus a limited number of users, maybe interactivity shows up a little earlier in the timeline. The second point is about breaking down access barriers. If a computer has a keyboard hooked up to it, then that's an obvious step in the right direction. That said, something like a serial obvious step in the right direction. That said, something like a serial interface could serve a similar purpose. We're just looking for a way that data can be directly pushed into the computer and pushed pretty quickly. And, well, anything multitasking seems to go with interactivity. That is point three in a nutshell. This is mainly because

timesharing was developed as an alternative to batch processing. At least, that's an easy reductionist view of things. It may be a little off base, but good enough for this type of investigation. So let's start filling in the list. The first stop is an experimental machine that had some type of direct input. So, hey, that's at least two of the three criteria met. Will this first option bear fruit? Maybe. Whirlwind was probably one of the coolest machines to escape the 1940s. The machine was operational by 51, but much of its development was carried out during the

end of the previous decade. If you want all the details, then I can recommend my earlier episode that covers Whirlwind, or the book Project Whirlwind by Kent Redmond and Thomas Smith. That's a great text that should really be the go-to when discussing Whirlwind. It was also published, funnily enough, by DEC. Go figure. Anyway, Whirlwind is notable for being the first so-called real-time computer. The machine was initially designed to drive aircraft simulations, so it was built specifically to handle real-time inputs and provide quick feedback. So far, that sounds pretty close to the interactivity target. Instead of looking at the cool new interfaces in this computer, I want to look at how it leveraged some existing technology, the FlexoWriter.

We're already entering some very obscure territory. The Fryden Flexo Writer was basically a brand-name teleprinter. It's this big automatic typewriter that can receive data to type, punch data onto tape, and even transmit data over a line. Well, over a physical wire. We aren't up to modem stuff quite yet. On the surface, this sounds like exactly the right type of device for an early REPL interface. It's all-in-one unit. A user can sit in front of the input device and the output device at the same time. That means instant input and, hopefully, instant feedback. That's very fancy indeed.

It's widely reported that Whirlwind had a FlexoRider hooked up to it. But how exactly was it used? Was Whirlwind taking full advantage of this machine? Well, this is where we start running into problems. My copy of Redmond & Smith is actually silent on the matter. It doesn't mention the FlexoRider at all. A 1952 report on Whirlwind had this to say about the FlexoRider's use, quote, It is also desirable to have a keyboard available which will allow rapid insertion of particular data into the machine during the course of a calculation. For similar use, means must be provided for converting from mechanical and electrical signals to binary code, and for inserting such data in the machine."

To me, this sounds more like the FlexoWriter was a tool of convenience instead of the main window into the computer. There are still more reports that mention the FlexoWriter acting as... There are still more reports that mention the FlexoWriter acting as... a printer. It's also used as a standalone machine to translate data stored on tape into human-readable text. This is still in a very non-interactive type of domain. That said, Whirlwind still had an interactive interface. That was kind of the whole point of the machine, after all. The computer had another interesting output device, a modified oscilloscope. This let Whirlwind plot simple vector graphics. In conjunction with a light pin, a very simple

pointing device that could be pressed to the scope, it was possible to provide an instant interactive interface. Text could also be plotted on the scope, so in a way this could be considered a text mode interface, but I think that's a bit of a stretch. This does take us in an interesting direction, though. Work done on Whirlwind would find its way into a much larger project, SAGE, the Semi-Automatic Ground Environment. This was a massive nationwide network of radar sites and information collection centers. Its goal was to protect the U.S. from air incursion by the Soviet Union. It's all very Cold War. One of the defining features of SAGE was its

interface. Many multiple users would sit in front of these giant round displays that visualized a region of US airspace. Using a light gun, an operator could interact with the display, thus viewing and editing information on any given radar blip. That solidly satisfies some of my search criteria. We have a computer that has an interactive component, a way to display information, and multitasking, or at least a multi-user type of system. The issue is, in a weird twist, the lack of text. Sage didn't really do text inputs. You can actually find some really interesting papers about trying to overcome this. Most Sage terminals didn't have keyboards, so during the 1950s there

was a drive to create this language that was fully graphical, so a normal user could sit back and program at one of these big radar dishes. Part of that was making these little on-screen keyboards. It's all very fascinating, but it isn't really REPL, so I think we need to just disregard the whole Whirlwind lineage. The next plan of attack is to just ditch the whole hardware side. It's turned out to be a pretty confusing line of inquiry. I've found so far that terminals were kind of used and abused in the early days of computing. There are a number of computers from the 40s and 50s that simply used terminals as handy, available printers. So looking for computers that used teletypes doesn't really point us in the right direction. I mean, the Harvard Mark I and a number of Zeus's really early machines use teletypes, just not for text processing in any way.

So instead, let's switch to the software approach. As a software guy, I think that may be a bit more my speed. Multitasking, aka timesharing, is really the early domain of REPL. In this setup, multiple users connected up to a central computer remotely. A user sits at a terminal and types in commands and then waits for feedback from the computer. Now, that is the good stuff. That's interactive and textual. But here from the computer. Now, that is the good stuff. That's interactive and textual. But here's the skinny. This text-based timesharing doesn't really exist until the early 1960s.

The papers I've read on timesharing don't really make a huge deal out of the text interface, so I can only assume that text was already an established regime. So, using my powers of deduction, I'm going to guess that there were pre-timesharing systems that used text interfaces. So, are there earlier operating systems that used text? Well, once again, that becomes really difficult to figure out. Some of the first operating systems pop up on IBM vacuum tube computers, namely the 701, 704, and 709. Early operating systems would appear totally foreign to a modern computer user. They were, essentially, a way to automate batch processing. These were sometimes called resident programs, because once loaded, the software would stay resident in memory. The operating system would allocate resources, manage jobs, and in some cases provide an environment for other programs to

run under. This environment is along the lines of a library. It's essentially a pile of useful function calls that any loaded program has access to. One of these early systems was called FMS, the Fortran Monitor System. This wasn't the first operating system, but I think it gives us the clearest view into what we're dealing with. FMS was created at IBM in 1959. It was, at least, assumedly based off other operating system work going on within IBM. FMS itself had one job, to streamline Fortran compilation. Now, the Fortran monitor was extremely simple. You'd start by loading FMS into the computer's memory, thus allowing it to take up residence. Then you grab your Fortran source code, which would have been stored on a stack of punch cards.

To issue a command to FMS, you prepare a special punch card that contains an asterisk followed by your command. These command cards can pass along information about the program being compiled and instructions on how to treat upcoming cards. It's simple, but it is useful. on how to treat upcoming cards. It's simple, but it is useful. Let's say you're a cleric who handles batches of data for an IBM 709. Normally, you attend to the machine. As one job finishes, you file away the outputs, reset the computer, and then prepare the next job. FMS can make your day a whole lot easier. Now you come into work in the morning, you load up each job, interspersing them with proper command cards. Pile that all into the big hopper, and you're set.

FMS will churn through each job in succession, following your command cards along the way. No fuss, no mess, and much less work. along the way. No fuss, no mess, and much less work. We aren't looking at an interactive system per se, but there's still some text processing going on here. Instead of manually loading and executing everything, you're telling the computer what to do with your cards. You are issuing a command. Sure, it happens to be on a punch card, but it's still close to a typed command. It's clear to see that we're approaching a REPL-type interface. The next step happens at MIT in 1961. That step is, partly to my frustration, timesharing. I just haven't been able to find a really solid single-user text interface. I keep breaking my own expectations this episode, which is probably a good thing.

FMS gives us a direct line to CTSS, the Compatible Timesharing System. CTSS, the Compatible Time Sharing System. You see, compatible doesn't mean that this operating system worked like some older text-based system. It was compatible with batch operations. It was compatible with the Fortran monitor. Now, CTSS was one of the first time-sharing systems out there, and as such, it started off with a demo. Everything good does. Eventually, CTSS would grow to be a pretty solid multi-user system, but it was initially servicing just two active users at a time. Their interface was textual, and it was provided by an old friend. From a 1961 progress report, quote,

The Flexo user will direct the operation of the computer by typing in commands. This is partially analogous to the control cards in the FMS system. In addition, the Flexo user has the ability to type in a symbolic program at the Flexo writer and perform some editing on it if necessary. End quote. The system was crude. Two FlexoRiders were wired up to MIT's 709. The computer itself was running a modified version of FMS, which was still able to accept punch cards. In general, FMS was always running in the background, just hanging out. In general, FMS was always running in the background, just hanging out.

When a Flexo user started typing, another program, a more powerful resident called the timesharing system, would interrupt the Fortran process and start attending to the user's needs. TSS, the timesharing system, read in a string of text from the Flexo writer. The program then decided what to do with that text. And once done, it would send a response back to that same FlexoWriter. Then TSS passed control back to the Fortran monitor and waited for the next key press. In other words, it looped. That, my friends, is REPL, plain and simple.

However, it was a very limited kind of interface. Users could only run a small handful of commands. You could load files, input code via the keyboard, compile and assemble programs, and run programs. I guess this was probably on par with the complexity of MS-DOS now that I think about it. It's simple, but it is a very workable start. This text interface finally gave programmers a taste of instant feedback. I really like to think about this in context. A handful of programmers at MIT were able to go from shuffling around punched cards to typing a

program directly into a computer. That's progress, to be sure. This would make for a really nice answer for us. REPL appears at the dawn of timesharing. The interactive text interface, well, that was really just an adaptation of what FMS was already doing. That sounds really nice. It's always easy to package up big developments like that. However, there are a number of wrenches to throw into these gears. There's this whole Lisp thing to deal with, after all. And this is where things get much, much more complicated. This is where I've reached a few sleepless nights, to say the least. Now, I actually kind of stumbled my way into the next big development in our story. One of Lisp's more common interfaces is an interactive shell, the actual REPL shell.

That's how I learned Lisp way back in the day, and I wager it's most people's first point of contact with this language. In this interface, you just type Lisp snippets in, and it executes them. You can even build whole programs up one line at a time. It's a really nice way to check out the language, and if you're skilled enough at it, it's a really cool interface. Now, some cursory research will tell you that the first interactive version of Lisp was programmed for the PDP-1 in 1964. And while that story is true, well, it turns out there was an earlier interactive version of Lisp. Well, it turns out there was an earlier interactive version of Lisp. The stumbling part here happened when I was tracking down information on the PDP-1 version.

Of course, that took me to some of McCarthy's writing, the Lisp creator himself. In his history of Lisp, McCarthy mentions an earlier implementation that he jokingly called Time Stealing Lisp. This was a single-user interactive Lisp shell, an actual REPL shell that was developed at MIT. McCarthy's retelling is a little vague, to say the least. Apparently, a Flexo writer had been hooked up to an IBM 704. Users were able to type in programs and get outputs. That sounds like REPL to me, at least. So the question becomes one of timeline. Was this Lisp program earlier than the CTSS demo? Luckily, we have primary sources to fall back to. The Lisp 1 manual was completed in March of 1960, which puts it a little bit before the first CTSS demo. The manual describes a system called

Lisp Flexo. And as you might be able to guess, it's a version of Lisp that uses a Flexo writer. And it's fully interactive. This is exactly what McCarthy hinted at in his history, and it pushes back the timeline by maybe as much as a year. It also appears that Lisp Flexo was taking advantage of earlier timesharing experiments conducted at MIT. taking advantage of earlier timesharing experiments conducted at MIT. But that's where I hit references to memos that seem to no longer exist. Lisp's Flexo is as far back as the MIT trail goes here. So what was this early shell like? In some ways, it's very familiar. Once the REPL shell was loaded up, it would start printing to the FlexoRider. The first thing you'd see is FLX, an identifier that you were, indeed, sitting at a Frieden

FlexoRider, that was followed by the word GO. That was how the computer said it was done processing. You were even presented with a prompt, In this case, it was a colon, which indicated that the machine was ready to take inputs from the FlexoWriter. Just type in a chunk of Lisp, hit enter, and the computer would start evaluating your text. Of course, there are some unexpected aspects to this interface. The FlexoWriter would actually print out STOP when the computer was processing, as a way to let the user know that inputs would get rejected. We're also in this archaic era for Lisp, so the code only looks vaguely familiar. At first, I thought that maybe Lisp Flexo used some weird dialect, but no, I looked through the rest of the manual. Lisp 1 is very,

very different than future versions of Lisp, let's just say. One feature I didn't expect to see, and one that took me a little bit to understand, was TIN mode. The short explanation is that 10 mode is how Lisp Flexo allowed for multi-line inputs. You'd type 10 to enter this text mode. Then you could enter up to 10 lines of text. Pretty apt name. Once you were ready to run, you'd type RLN to run the lines. Here's the mind-bending part. At least, it's bending in the larger context. 10 mode allowed for line-based editing. The actual interface is really similar to the basic

interfaces that were used on home computers in the 80s and came from Dartmouth. Once in 10 mode, computers in the 80s and came from Dartmouth. Once in 10 mode, you'd start each line with a line number. They went between 0 and 9, so a little less cushy, but it's a similar idea. Notably, you could enter these in any order you wanted. Editing was simple. You'd just re-enter a line number to overwrite the existing text for that line. Disregarding some limitations, this functioned almost exactly like the text interfaces used for BASIC years later. In fact, this might make Lisp Flexo one of the earliest computer text editors, at least in a very limited sense. The interface is there, which I'd say is a pretty big part of the equation. So what should we make of all of this?

I know it's been a bit of a rambling path, but I think we've hit a pretty solid theory here. If I stick to the exact sources that I can dig up, then the first REPL interface, the first computerized interactive text interface, is Lisp Flexo. It's this almost forgotten experimental Lisp system that was probably only used in one lab at MIT in 1960. Its development was connected to MIT's larger work on timesharing in this period, so there's a nice lineage forming here. If I want to be more broad, and really, if I want to hedge my bet, then the first text interfaces were developed sometime in either 1959 or 1960 at MIT. They used IBM mainframes, probably the Colleg's 704. That interface used a Frieden FlexoWriter. My reason to hedge here comes down to that missing memo. It's the programming manual for the MIT FlexoWriter monitor interpreter system of the time-sharing program test.

time-sharing program test. Now, that may point to an earlier or even less known text interface, but I think going that far would be a bit of a fool's errand. When dealing with firsts, it's important to think about context. Now, I will admit, Lisp Flexo is already really obscure. It seems like it was only really experimental, not a workhorse kind of system. So if we go back any further on this line, we may find a similar text interface, but it would probably be an even smaller scale test. At that point, one has to wonder, well, what's the point? If the technology doesn't have some has to wonder, well, what's the point? If the technology doesn't have some connection to a larger lineage, then it's just a blip. That doesn't mean it's not interesting, just less impactful.

One example here that I actually run into a lot is the CADC chip developed for the F-14 Tomcat fighter jet. This might seem like a non sequitur, but bear with me. The CADC was a microprocessor developed for the Navy. The processor wrapped development in 1970, which means this is a microprocessor a solid year older than the Intel 4004. That means that, technically speaking, the CADC is the first microprocessor. And sure, that's true, but there's a complication. That chip was classified well into the 1990s. Entire generations of microprocessors rose and fell before anyone besides a select few learned about this engineering first. Does that mean that the CADC is unimportant? No, of course not. It just means that it wasn't as impactful to digital history as the 4004. I think going deeper than Lisp Flexo will probably put us in a similar situation. But hey, this is Advent of Computing, and you know me, I can't resist

ruining my own conclusions. I think I've built a pretty solid and very reasonable argument for Lisp Flexo as the first REPL interface. But what about some less reasonable contenders? To get into possible alternatives, we have to go way back to the murky dawn of computing. Finding the first computer is also one of those tricky tasks. We get our first batch of definitive, solid options around 1944-1945, but there are also somewhat similar systems developed well before that date. One such machine was George Stibitz's complex numerical computer. This was a relay-based calculator developed at Bell Labs. The project would start in 1938 with a finished model demonstrated in 1940. This puts us well before the World War II pack of machines. Stibitz's machine wasn't a computer in the strictest sense. It was basically

a really fancy electronic calculator. In this context, complex doesn't have anything to do with the convolutions of the machine. Rather, the calculator could handle mathematics that involved imaginary numbers. This machine, sometimes just called the Model 1, couldn't do conditional execution. There were a number of factors that made that impossible. It was really just a big calculator, but in retrospect, it had a lot of features that presaged the later development of digital computers. Stivitz chose to use relays as logic elements, for instance. So while this isn't a full-on Turing-complete computer, it's not going to be running Doom, it is pretty close, at least technology-wise.

The CNC was able to add, subtract, multiply, and divide complex numbers. On its own, that's neat, yet it lacks a certain wow factor. We can kick the CNC up a notch by looking, of course, at its interface. That is the theme of tonight. You see, this machine used a terminal. And I don't mean it had a flexorider hooked up as a cheap printer. I mean the CNC took inputs and printed outputs on the same terminal interface. Now, this isn't at the same level as my beloved Lisp Flexo or some other text shell. There's a

reason I'm putting the CNC Model 1 in the dubious category. Stibitz had hooked an old-style teletype up to the machine. This isn't even as advanced as a FlexoRider. This is literally a machine meant for transmitting and receiving telegrams. These are big, oafish devices, but they were pretty standard equipment. The model used by Bell had a few modifications, which we will examine in due time. The CNC could only do complex arithmetic, and... Oh, I guess for the interface to make sense here, I gotta give a quick crash course in complex math. A complex number is actually a lot easier to understand than it sounds. It's composed of a real part and an imaginary part. A real number in this case is just a normal number, you know, the kind you see every day.

It's composed of ones, zeros, nines, fives, everything in between. An imaginary number is a real number multiplied by the square root of negative one. If you aren't in the math world, that should sound kind of dumb and useless, but the root of minus one has some unique properties that make it useful in certain types of physics. It shows up in a lot of electronics and magnetism work, for instance. This imaginary part, that root minus one, is notated as the letter i. So a full complex number is written out as a plus bi, where a is the real component and b is the imaginary component. If you see something like 1 plus 2i, then you know somewhere nearby is about to whip out a calculator. Now, complex math is, pardon the pun,

a little more complicated than normal everyday mathematics. There are special rules for how to deal with imaginary components as opposed to the real component. Certain operations don't act in expected ways. This can make it a bit error-prone, and it's a nice task to automate away. That's exactly the role that the CNC fell into. The computer's interface follows the mathematical notation pretty closely with some exceptions. To start a calculation, an operator would simply type in the expression in question. The CNC was a fixed-point machine, so each number had to have the correct amount of decimal places. That's not really too odd, you just end up needing to hammer in something like 0.2000 instead of 0.2. Not really a big deal. The notation for the imaginary component

is where we diverge into something different. You see, the CNC wasn't operated with any old normal terminal. Stibitz had this special teletype with a custom keyboard. It had buttons for each digit, the plus, a minus, divide, multiply, equals, and it had plus I and minus I buttons. The imaginary component of a complex number can either be positive or negative, so the plus i and minus i fill the full complement. But this should be a little strange. Instead of typing out a plus followed by an i, you press a special key. But hey, whatever. That's just an early terminal for you, right? So you type in a complex number.

Then you put in your operation, followed by the next complex number. Once everything's lined up, the equals button would tell the computer to start crunching those numbers. The result was then sent back to the teletype and printed right after the equals sign. We actually have a printout of this process. At least, I think we do. There's this 1940 article that I'll link to titled, quote, Electronic Calculating Machine Devised for Complex Problems.

It's probably one of the first cheesy articles about a digital brain. Anyway, at the bottom of the first cheesy articles about a digital brain. Anyway, at the bottom of the first page is what looks like a mimeograph of a CNC session. The image's caption implies it's taken from a printout, but it doesn't say so explicitly. It may have been retyped for all I know. Either way, we know exactly what the interface looked like. This article also describes the famous 1940 demo at Dartmouth. This was at the so-called Summer Session of the Mathematical Association of America. I say so-called because it occurred on September 11th, not exactly the height of summer.

The press from MAA called it a summer session, so what are you going to do? During this demo, Stibitz connected to the CNC remotely over a telephone line. Bell, at this point, was the phone company, after all. He was able to hook up a terminal and operate the CNC from hundreds of miles away. This was done in what appeared to be clear text. On the surface, this sounds like the big mythological moment we've been looking for. It's the mother of all demos, but for text interfaces. So, was this the first REPL? Is this a dark horse candidate that we have to consider?

Well, I don't think so. One issue is that, well, you know, the CNC wasn't exactly a computer. The name makes that distinction a little annoying to keep straight, but it was a fancy calculator. There's also a more nitpicky argument to be had. In my head, at least, the weird notation can only mean one thing. The CNC was using a pretty specialized character set. This part is a little speculative on my part. We have historical recollections by Stibbets and some contemporary accounts to go off of, plus pictures of the CNC and its terminal. We don't, however, have Stibitz's first article on the computer. That paper, calculating with telephone equipment, seems to be lost.

I even put out a call in my Discord group to try and find it, and we found a few references, but we can't find the paper itself. There is a collection of Stibitz's papers at Dartmouth, but if it includes this specific paper, then the finding guide doesn't say so. The paper would also in theory show up in the Proceedings of the Mathematical Association of America, but I've looked through those volumes and only found citations. I think this thing is just in some poorly labeled file folder and I haven't had the time to send out a flurry of requests to some poor archivists. Anyway, this is all to say that I'm making wild accusations about Bell's own machine.

say that I'm making wild accusations about Bell's own machine. My informed guess is that the CNC Model 1 isn't handling any text at all, at least not in a recognizable way. This argument hinges on those weird plus-i and minus-i characters. Those don't really show up in any text encoding schemes that I can think of, discounting something exotic like a special Unicode page. It's likely that Stibitz was piggybacking off some existing telegraph format like BotoCode. That would already have numbers and letters and was already being synced down wires, but Stibitz only needed numbers and a handful of special characters. That means there would probably be plenty of space to change up the encoding. I'm going to stop before I ramble on too much here. The point is that the CNC was doing something special purpose.

It didn't have some program parsing incoming text and then trying to execute the data it received. The CNC saw numbers, then loaded them, and ran an operation that was tucked in the exact right place in a data packet. It looks like a REPL interface, but it's pretty divorced from the fuller context here. I just don't think we can make a great argument for the CNC being the first full-text interface. for the CNC being the first full-text interface. This leads me to one final option that I think really illustrates the confusion around this quest. This quote comes from A History of Computing in

the 20th Century. That text is a collection of recollections written by those who were responsible for the digital revolution. That includes an essay by Stibitz that I used in this previous section. While searching through the text for some relevant information, I stumbled into this. Quote, I had thought that SEAC was the first with a remote terminal. In the middle of 1950, we wanted to demonstrate it to the people of the Bureau of Standards, and so put a teletype a End quote. Those words were written by Ralph Sloots, one of the researchers at the National Bureau of Standards that worked on the SEAC project. Running into this passage kind of set my mind reeling. Sloots

was at the scene of the crime, so to speak. If he can't even make sense of which computers were using remote interfaces or text interfaces, then what hope do I have? For that matter, what was SEAC doing with a terminal? SEAC was a computer built at the National Bureau of Standards. It would first start operations in 1950. It was one of the first stored program computers, so it's on a pretty modern level of complexity, at least conceptually speaking. So how is it using a terminal? In this case, we're dealing with a plain old teletype, not a brand-name flexo-writer. The teletype was also modified and connected to SEAC through an input-output buffer. Data was transmitted as serial packets from the teletype into that buffer,

that's pulses of ones and zeros on an unadorned wire. Once inside SEAC, the serial data was converted into actual numbers, then processing could occur on said data. Output just worked in reverse. SEAC took some numbers, turned them into serial pulses of ones and zeros, then sent them over an unadorned wire from the output buffer. If the teletype was listening, then it could read in those pulses and print the resulting data on a paper feed. could read in those pulses and print the resulting data on a paper feed. That's only one mode of operation. The buffer here is really the secret sauce, something that SEAC and many other computers in this era shared in common. You see, you could select what input and what output device you wanted to connect to that buffer. The teletype was just one option. With a twist of

the dial, SEAC could be set to take inputs from paper tape or even magnetic wire. It's pretty cool. Now, this also worked with outputs. You could print to teletype or you could put outputs onto something more solid. So SEAC had a teletype as an I.O. device, but that was only one device of many. The only special part about the teletype, at least as far as the computer was concerned, was that it had a pretty low bandwidth. This seems to be the main way that early computers used teletypes, and, blessed be their name,

Frieden FlexoRiders. The Manchester Bay and UNIVAC-1 had the same type of loosely coupled terminal setups. So anything that could be done via a teletype could also be done using paper tape or punched cards depending on your setup. One of the big use cases here, for SEAC at least, was debugging. Circular of the Bureau of Standards number 551 describes SEAC and its related projects as they stood in 1955. That's about five years into the computer's lifespan, so it gives us a good settled view of the machine. This document

explains that the terminal could be used as a tool for debugging. This was a fairly straightforward process. The operator flipped the stop switch and hit another button to produce a printout of the current instruction or the state of certain registers. The operator could then modify instructions or certain data in memory. This type of stop-and-fiddle debugging is a very effective tool. It was also in use on a number of computers in this period. With SEAC, it could all be accomplished from the terminal. Kind of. There were ancillary buttons on the computer's control panel that had to be operated to do the whole print and input thing. Plus, the terminal wasn't the only way to handle this. The circular does explain that the terminal was the most common option for this type of debugging,

but you could just as easily have used paper tape. In that sense, the teletype isn't filling a special role. That said, the teletype did have its uses. Sloots said that in 1950 there were remote demos of SEAC using a teletype. One nearby the computer somewhat, and one in a more distant hotel. I can verify at least one of these events. In a 1976 oral history, Sloots had this to say, It was only a very few months after we first operated it when we wanted to demonstrate it to the Bureau of Standards, and we couldn't get nearly enough people in the room in which it was built to do that, so we put a remote terminal

on it halfway across the bureau grounds in a lecture hall. End quote. From the oral history, it sounds like SIAC was simply running a program over Teletype. This could have definitely taken inputs and did produce outputs, but this doesn't sound like it was an interactive text interface. This is confounded and complicated by two factors. First, is that SEAC didn't use a full-stroke keyboard. The teletype unit it used had been modified, much like with the CNC. SEAC's teletype could only output hexadecimal and a carriage return. So, even if there was a fully interactive interface, it would have had to be a numerical one. Second, we have the auto-monitor. This was a feature added to SEAC in 1951 that output the current operation to any output device. In other words, it could let an operator follow SEAC's work from a handy-dandy terminal. I bring this up as a complication

because, well, it feeds back into the whole debugging hypothesis. SEAC wasn't using the teletype as a primary interface. It was, in large part, a debugging tool. This puts us in the same position we saw with Stibbit's CNC and with many other leads this episode. SEAC has these features that make it sound like it used REPL. But under the hood, we're just not quite there. Alright, with that, I'm closing the book on this episode. Thanks for sticking with me until the end. I know this one has had some twists to it. I think I've answered some of my initial questions while also raising some new ones. Were there text interfaces in existence prior to timesharing? I think that's a definitive yes.

As we saw with Lisp Flexo, my one shining and solid example, you don't need timesharing computers to make interactive text interfaces. That said, Lisp Flexo was developed on the road to timesharing. Is there a single program we can point to as the first interactive text shell, or even a single computer? Well, that's a more tricky question to answer. There are a lot of systems that had aspects of REPL. Some of the earliest computers even used terminals, at least in some capacity.

I don't think it would be out of line to posit that text interfaces developed gradually and naturally. People were already dealing with keypads and keyboards, printers and typewriters. It would only take some glue to make that into a slick interface. I'm sure a much deeper exploration would turn up a number of totally unrelated text interfaces that I haven't even found references to. Does this make the birth of the text interface different than the creation of the graphical interface? Well, I don't think so. We have all this mythology around the GUI, but the graphic story is another complex tale. There were researchers both before and after the mother of all demos that created systems with aspects of a GUI. Pointing devices did exist prior to the mouse. In general, I hope this episode

serves as another one of my classic warnings. When we try and reduce things to firsts or to simple stories, we run into problems. History just isn't simple. It's all very messy. isn't simple. It's all very messy. But within that mess, we can hopefully find some useful truths. Thanks for listening to Advent of Computing. I'll be back in two weeks' time with another piece of computing's past. And hey, if you like the show, there are a few ways you can support it. If you know someone else who'd be interested in the history of computing, then please take a minute to share the show with them. You can also rate and review the podcast on Apple Podcasts. If you want to be a super fan, you can support the show directly through merch or signing up as a patron on Patreon. Patrons get early access to episodes, polls for the direction of the show, and bonus content.

I actually just put up a brand new bonus episode talking about meta languages, so now's a great time to sign up. Really, any time is a great time to sign up. You can find links to everything on my website, adventofcomputing.com. If you have any comments or suggestions for a future show, then go ahead and shoot me a tweet. I'm at adventofcomp on Twitter. And as always, have a great rest of your day.