Transcript for #109 – Brian Kernighan: UNIX, C, AWK, AMPL, and Go Programming

If I can remember that far back, it was some while ago. So I think the gist of it is that at Bell Labs in 1969, there were people who had just finished working on the Multics project, which was itself a follow on to CTSS. So we can go back sort of an infinite regress in time, but the CTSS was a very, very, very nice time sharing system. It was very nice to use. I actually used it as that summer I spent in Cambridge in 1966.

So CTSS looked like kind of like a standard time-juring system. Certainly, if the time it was the only time-sharing, let's go back to the big, what's the time-sharing system? Okay, in the beginning was the word and the word is. And then there was time-sharing systems. Yeah, if we go back into let's call it the 1950s and early 1960s, most computing was done on very big computers physically big, although not terribly powerful, but today standard that were maintained in Very large rooms, and you use things like bunchcards to write your programs on, talk to them. So you would take a deck of cards, write your program on it, send it over a counter, head it to an operator, and some while later back would come something that said, oh, you made a mistake, and then you'd recycle. And so it was very, very slow. So the idea of time sharing was that you take basically that same computer, but connect to it with something that looked like an electric typewriter. that could be a long distance away, it could be closed. But fundamentally what the operating system did was to give each person who was connected to it and wanting to do something a small slice of time to do a particular job. So I might be editing a file, so I would be typing. And every time I hit a keystroke, the operating system would wake up and said, oh, he typed character. Let me remember that. And then it would go back to doing something else. So it'd be going around and around a group of people who were trying to get something done, giving each a small slice of time and giving them each the illusion that they pretty much had the whole machine to themselves. And hence, time sharing that is sharing the computing time resource of the computer among a number of people who were doing

Pretty much that was the idea. Yes, you had, if it were well done and if it were fast enough and other people weren't doing too much, you did have the illusion that you had the whole machine to yourself and it was very much better than the punch card model. And so CTSS, the compatible time sharing system, was I think arguably the first of these. It was done, I guess, technically 64 or something like that. It ran on IBM 7094, slightly modified to have twice as much memory as the norm. It had two banks of 32k words instead of one.

E2K words was 36 bits. So call it, you know, about 150 kilobytes times two. So by today standards that's down in the noise. Yeah, the time that was a lot of memory and memory was expensive. So CTSS was just a wonderful environment to work on. It was done by the people in MIT, led by Fernando Corbatoff, Corby who died just earlier this year. and a bunch of other folks. So I spent the summer of 66 working on that at a great time. I met a lot of really nice people and indirectly new of people at Bell Labs who were also working on a follow-on to CTSS that was called Multics. The Multics was meant to be the system that would do everything at CTSS did but do it better for a larger population.

The answer is I don't have a clue. I think the basic idea was nothing more than who all wants to get something done. Suppose things are very quiet in the middle of the night. then I get all the time that I want. Suppose that you and I are contending at high noon for something like that then probably the simplest algorithm is around Robin one that gives you a bit of time gives me a bit of time and then we could adapt to that like what are you trying to do or you text editing or are you compiling or something and we might adjust the scheduler according to things like that.

Well, it was meant to be much more than that. So Multics was the multiplexed information in computing service, and it was meant to be a very large thing that would provide computing utility, something that where you could actually think that is just a plug-in-a-wall service. Sort of like cloud computing today, same idea. But 50 ideas earlier. And so what Multics offered was a richer operating system environment. piece of hardware that was better designed for doing the kind of sharing of resources and presumably lots of other things.

I don't know where that was the dream. I wasn't part of it at that point. Remember, I was an intern for summer. But my sense is given that it was over 50 years ago. Yeah, they had that idea that it was an information utility that it was something where if you had a computing task to do, you could just go and do it. Now, I'm betting that they didn't have the same view of computing for the masses. Let's call it the idea that, you know, Your grandmother would be shopping on Amazon. I don't think that was part of it. But if your grandmother were a programmer, it might be very easy for her to go and use this kind of utility.

Oh, short answer. Absolutely not. I've no clue. I'm not sure I had a dream. It was a dream job in the sense that I really enjoyed what I was doing. I was surrounded by really, really nice people. Cambridge is a very fine city to live in in the summer. Less so on the winter when it's nose, but in the summer it was a delightful time. And so I really enjoyed all of that stuff. And I learned things. And I think the good fortune of being there for summer led me then to get a summer job at Bell Labs the following summer. And that was going to useful for the future.

Yeah, so Bell Labs is physically scattered around at the time, scattered around New Jersey, the primary location. It was in a town called Murray Hill, where a location called Murray Hill is actually that across the boundary between two small towns in New Jersey called New Providence and Berkeley Heights. Think of it as above 1520 miles straight west of New York City, and therefore, but in our north of here in Princeton, And at that time, it had a number three or four thousand people there, many of whom had PhDs, and mostly doing physical sciences, chemistry, physics, materials, kinds of things, but very strong math. And rapidly growing interest in computing is people realized you could do things with computers that you might not have been able to do before. You could replace labs with computers that had worked on models of what was going on. So that was the essence of Bell Labs. And again, I wasn't a permanent play there. I was that was another internship. I got lucky in internships.

Well, I think there was very definitely something special. I mentioned the number of people, so very large number of people, very highly skilled, and working in an environment where there was always something interesting to work on because the goal of Bell Labs, which was a small part of AT&T, which provided basically the country's phone service. The goal of AT&T was to provide service for everybody and the goal of Bell Labs was to try and make that service keep getting better, so improving service. And that meant doing research on a lot of different things, physical devices like the transistor or fiber optic cables or microwave systems, all of these things the labs worked on. And it was kind of just the beginning of real boom times in computing as well. When I was there, I went there first in 66. So computing was at that point fairly young. And so people were discovering that you could do lots of things with computers.

So, in spite of having an enormous number, really good ideas, lots of good people working on it. Fundamentally, didn't live up at least in the short run. I think, ultimately, really ever, to the its goal of being this information utility. It was too expensive and certainly what was promised was delivered much too late. And so, in roughly the beginning of 1969, Bell Labs, pulled out of the project. The project, at that point, had included MIT, Bell Labs, and General Electric, General Electric made computers. General Electric was the hardware operation. So Bell Labs, realizing this wasn't going anywhere on a time scale. I cared about pulled out of the project. And this left several people with an acquired taste for really, really nice computing environments, but no computing environment. And so they started thinking about what could you do if you're on a design, a new operating system that would provide the same kind of comfortable computing as CTSS had, but also the facilities of something like Maltakes sort of brought forward. And so they did a lot of paper design stuff. And at the same time, Ken Thompson found what is characterized as a little used PDP7. where he started to do experiments with file systems, just how do you store information on a computer and you do efficient way. And then this famous story that is way flinted way to California for three weeks, taking their one year old son and three weeks. And he sat down and wrote an operating system, which ultimately became unix. So software productivity is good in those days.

Yeah, it's a piece of part where it was one of early machines made by digitally equipment corporation deck. And it was a mini computer, so called it had, yeah, I would have to look up the numbers exactly, but it had a very small amount of memory, maybe 16k, 16 bit words or something like that, relatively slow. probably not super expensive, maybe again, making this up. I'd have to look it up 100,000 dollars or something like that, which is not super expensive in those days, right? It was expensive. It was enough that you and I probably wouldn't be my buy one, but a modest group of people could get together. But in any case, in it came out if I recall in 1964. So by 1969, it was getting a little obsolete, and that's why it was little used.

Well, let me correct one thing. I had nothing to do with it. So I did not write it. I have never written operating system code. And so I don't know. Now an operating system is simply code. And this first one wasn't very big, but it's something that lets you run processes of some, let you execute some kind of code that has been written. It lets you store information for periods of time. So that it doesn't go away when you turn the power off or reboot or something like that. And there's a kind of a core set of tools that are technically not part of an operating system, but you probably need them. In this case, Ken wrote an assembler for the PDP7 that it worked. He did a text editor so that he could actually create text. He had the file system stuff that he had been working on, and then the rest of it was just a way to load things executable code from the file system into the memory, give it control, and then recover control when it was finished or in some other way.

Yeah, PDP-7 old assembler that can create it. These things were assembly language until probably the call it 1973 or 74 something like that.

I think it's hard. It's been a long time since I wrote assembly language. It is absolutely true that in some language, if you make a mistake, nobody tells you there are no training wheels whatsoever. And so stuff doesn't work. Now what? And there's no debuggers. Well, there could be debuggers, but that's the same problem right? How do you actually get something that will help you debug it. So part of it is is an ability to see the big picture. Now these systems were not big in the sense of today's picture. So the big picture was in some sense more manageable. I mean then realistically there's an enormous variation in the capabilities of programmers and Ken Thompson who did that first one is kind of the singularity in my experience of programmers. with no disrespect to you or even to me. He's in an eye.

It's quite surprising, and you asked earlier about predictions. The answer is no, there's no way you could predict that kind of evolution. And I don't know whether it was inevitable or just a whole sequence of blind. A lot of cases back and more of the latter. And so I look at it and think, gee, that's kind of neat. I think the real question is what does Ken think about that? because he's the guy arguably from whom it really came. You know, tremendous contributions from Dennis Richie and then others around in that vellabs environment, but you know, if you had to pick a single person, that would be

Oh, there's a lot of them in a sense. And again, it's a question. If can you resurrect them in real life? It's memory fails. But I think, uh, Part of it was that Bell Labs at the time was a very special kind of place to work because there were a lot of interesting people. And the environment was very, very open and free. It was a very cooperative environment, very from the environment. And so if you had an interesting problem, you go and talk to somebody and they might help you with the solution. And it was a kind of a fun environment, too, in which people did strange things and often tweaking the bureaucracy in one way or another. So rebellious and put it in some kinds of ways. In some ways, yeah, absolutely. I think most people didn't take too kindly to the bureaucracy and I'm sure the bureaucracy put up with an enormous amount that they didn't really want to.

I think one aspect of the fundamental philosophy was to provide an environment that made it easy to write or easier. productive to write program. So it was meant as a programmer environment. It wasn't meant specifically as something to do some other kind of job. For example, it was used extensively for word processing, but it wasn't designed as a word processing system. It was used extensively for lab control, but it wasn't designed for that. It was used extensively as a front end for big other systems, big dumb systems, but it wasn't designed for that. It was meant to be an environment where it was really easy to write programs. That's a program which could be highly productive. And part of that was to be a community and there's some observation from Dennis Richie. I think at the end of the book that says that from his standpoint, the real goal was to create a community where people could work as programmers on a system. And I think in that sense, certainly for many, many years, it succeeded quite well. at that. And part of that is the technical aspects of because it made it really easy to write programs. People did write interesting programs. Those programs tended to be used by other programmers. And so it was kind of a virtuous circle of more and more stuff coming up that was really good for programmers.

It was a blast. It really was. You know, I like to program. I'm not a terribly good programmer, but it was a lot of fun to write code and in the early days there was an enormous amount of what you would today I suppose, called low hanging fruit. People hadn't done things before and this was this new environment and the whole combination of nice tools and very responsive system and tremendous colleagues made it possible to write code. You could have an idea In the morning, you could do an experiment with it. You could have something limping along that nighter the next day and people would react to it and they would say, oh, that's wonderful. But you're really screwed up here. And the feedback loop was then very, very short and tight. And so a lot of things got developed fairly quickly that In many cases still exist today, and I think that was part of what made it fun, because programming itself is fun. It's puzzle-solving in a variety of ways, but I think it's even more fun when you do something that somebody else then uses. Even if they wind about it not working, the fact that they used it is part of the reward mechanism.

Certainly before the internet, it was mostly physical right there, you know, somebody who came into your office and say something.

Yeah, no Bell Labs was fundamentally one giant building and most of the people were involved in this unique stuff. We're going to enter three quarters and there was a room. Oh, how big was it? Probably call it 50 feet by 50 feet. Make up a number of that in which had some access to computers there as well as in offices and people hung out there and it had a coffee machine and so that there was it was mostly very physical we did use email of course and but it was fundamentally all for a long time all along one machine so there was no need for internet

Well, I think that's very nice, but in a sense it's survivor bias, and if it hadn't happened at Bell Labs, there were other places that were doing really interesting work as well. Xerox Park is perhaps the most obvious one. Xerox Park contributed enormous amount of good material. And many of the things we take to figure out today in the same way came from zerox park experience. I don't think they capitalized in the long run as much their parent company was perhaps not as lucky in capitalizing on this who knows. But that would that certainly another place where there was a tremendous amount of influence. There were a lot of good university activities MIT was obviously no slouch in this kind of thing and others as well.

So I think that's a mischaracterization in the sense. It absolutely was not open source. It was very definitely proprietary, licensed, but it was licensed freely to universities in source code form for many years. And because of that, generations, of university students and their faculty people grew up knowing about Unix and there was enough expertise in the community that then became possible for people to kind of go off in their own direction and build something that looked Unix like. The Berkeley version of Unix started with that license code and gradually picked up enough of its own code contributions notably from people like Bill Joy. that eventually it was able to become completely free of any AT&T code. Now there was an enormous amount of legal jacking around this that in the late early to late 80s, early 90s, something like that. And then not, I guess the open source movement might have started when Richard Stallman started to think about this in the late 80s. And by 1991, when Torvald's decided he was going to do a Unix-like operating system. There was enough expertise that in the community that first he had a target he could see what to do because the kind of the UNIX system call interface and the tools and so on were there. And so he was able to build an operating system that at this point when you say UNIX in many cases what you're really thinking is Linux.

Right. And a very, very large number of universities had the license and they were able to talk to all the other universities who had the license. And so technically not open technically belong to AT&T, pragmatically pretty open.

I think part of the reason for efficiency was that it began on extremely modest hardware. Very, very, very tiny. And so you couldn't get carried away. You couldn't do a lot of complicated things because you just didn't have the resources, either processor, speed, or memory. And so that enforced a certain minimality of mechanisms. and maybe a search for generalizations so that you would find one mechanism that's served for a lot of different things rather than having lots of different special cases. I think the file system in Unix is a good example of that file system interface and its fundamental form is extremely straightforward. And that means that you can write code very, very effectively for the file system. And then one of those idea, one of those generalizations is that gee, that file system interface works for all kinds of other things as well. And so in particular, the idea of reading and writing to devices is the same as reading and writing to a disk that has a file system. And then that gets carried further in other parts of the world processes become and effect files in a file system. And the plan 9 operating system, which came along, I guess in the late 80s, or something like that, took a lot of those ideas from the original Unix and tried to push the generalization even further. So in plan 9, a lot of different resources, our file systems, they all share that interface. So that would be one example. We're finding the right model of how to do something means that an awful lot of things become simpler and it means there for the more people can do useful. Interesting things with them without them to think as hard about it.

I think it's some of each. It's some combination. Some of the art is figuring out what it is that you really want to do. What should that program be? What would make a good program? And that's some understanding of what the task is, what the people who might use this program want. And I think that's art in many respects. The science part is trying to figure out how to do it well. And some of that is real computer science stuff like what algorithm should we use at some point? Mostly in the sense of being careful to use algorithms that will actually work properly, scale properly, avoiding quadratic algorithms when a linear algorithm should be the right thing. that kind of more formal view of it, same thing for data structures. But also, it's, I think, an engineering field as well. An engineering is not quite the same in science, because engineering you're working with constraints. You have to figure out not only, so what is a good algorithm for this kind of thing, but what's the most appropriate algorithm given the amount of time we have to compute the amount of time we have to program what's likely to happen in the future with maintenance, who's going to pick this up in the future, all of those kind of things that if you're an engineer, you get to worry about, whereas if you think of yourself as a scientist, well, you can maybe push them over their horizon in a way and if you're an artist, what's that?

It's certainly much more the informal intermedal first. I don't write big programs at this point. It's been a long time since I wrote a program that was more than I call it a few hundred. or more lines, something like that. Many of the programs are right or experiments for either something I'm curious about or often for something that I want to talk about in a class. And so those necessarily tend to be relatively small. A lot of the kind of code I write these days tends to be for sort of exploratory data analysis where I've got some collected data and I want to try and figure out what nerf it's going on in it. And for that, those programs tend to be very small. Sometimes you're not even programming, you're just using existing tools like counting things. Or sometimes you're writing ox grips, because two or three lines will tell you something about a piece of data. And then when it gets bigger, well, when I will probably write something in Python, because that scales better up to college a few hundred lines, or something like that. And it's been a long time since I wrote programs that were much more than that.

So Ock is a scripting language that was done by myself L. A.O. on Peter Weinberger. We did that originally in the late 70s. It was a language that was meant to make it really easy to do quick and dirty tasks like counting things or selecting interesting information from basically all text files, rearranging it in somewhere or summarizing it.

Yeah, it's a very good for that kind of thing, and that's sort of what it was meant for. I think what we didn't appreciate was that the model was actually quite good for a lot of data processing kinds of tasks and that it's kept going as long as it has, because at this point it's over 40 years old, and it's still, I think, a useful tool. Well, this is paternal interest, I guess, but I think in terms of programming languages, you get the most bang for the buck by learning, oh, and it doesn't scale the big programs, but it does pretty pretty darn well on these little things where you just want to see all the somethings in something. So yeah, I find I probably write more hot than anything else on this point.

I think it's mostly the selection of default behaviors. You sort of hint at that at a moment and go, what doc does is to read through a set of files and then within each file it writes through each of the lines. And then on each of the lines it has a set of patterns that it looks for that's your org program. And if one of the patterns matches there is a corresponding action that you might perform. And so it's kind of a quadruply nested loop or something like And that's all completely automatic. You don't have to say anything about it. You just write the pattern in the action and then run the data by it. And so that paradigm for programming is very natural and effective one. And I think we captured that reasonably well in lock. And it does other things for free as well. It splits the data into fields so that on each line there is fields separated by white space or something. And so it does that for free. You don't have to say anything about it. And it collects information. It goes along like what line are we on? How many fields are there on this line? So lots of things that just make it so that a program which in another language, let's say Python, would be 510-20 lines in August, 1 or 2 lines.

Yeah, grab those everything.

And in some sense, yeah, right, because what is Grap? So, Grap is basically searches the input for particular patterns, regular expressions, technically of a certain class. And it has that same paradigm that Oct does. It's a pattern action thing. It reads through all the files and then all the lines in each file, but it has a single pattern, which is the regular expression you're looking for in a single action printed, if it matches. So in that sense, it's a much simpler version and you could write crappy and awkward as a one-liner. And I use crap probably more than anything else at this point, just because it's so convenient in that

I don't know, it's not strictly unique, but it's certainly focused there. And I think some of it's the weight of history that Windows came from MSDOS. MSDOS was a pretty pathetic operating system, although common on and unboundedly large number of machines. But somewhere in roughly the 90s, Windows became a graphical system. And I think Microsoft spent a lot of their energy on making that graphical interface what it is. And that's a different model of computing. It's a model of computing that where you point and click and sort of experiment with menus. It's a model of computing works. Right, rather well for people who are not programmers. I just want to get something done, whereas teaching something like the command line to non-programmers turns out to sometimes be an uphill struggle. And so I think Microsoft probably was right and what they did. Now, you mentioned whistle or whatever. It's called the winnings.

But there have been things like that for long a siguin, for example, which is a wonderful collection of take all your favorite tools from Unix and Linux and just make them work perfectly on Windows. And so that's something that's been going on for at least 20 years if not longer. And I use that on my one remaining Windows machine routinely because it It's for if you're doing something that is batch computing command suitable for command line That's the right way to do it because the windows equivalents are if nothing else not familiar to me

Yeah, perfect as too strong a word. It's way too strong a word. What I use by default, I have at this point a 13 inch MacBook Air, which I use because it's kind of a reasonable balance of the various things I need. I can carry it around. It's got enough computing horsepower, screens, big enough, the keyboard's okay. Um, and so I basically do most of my computing on that, um, I have a big iMac in my office that I use from time to time as well, especially when I need a big screen, but otherwise, uh, tends not to be used at much, um, uh, editor. I use mostly Sam, which is an editor that Rob Pike wrote long ago at Bell Labs.

Posts. It post dates both VI and Emax. It is derived from Rob's experience with EDI and VI. That's the original new next editor. Oh wow. Data probably before you were born.

So in ancient times, like call it the first time sharing system is going back to over time. But there were editors, there was an editor on CTSS that I don't even remember what it was called. It might have been edit, where you could type text, program text, and it would do something, or document text. You could save the text. And that's it. You could edit it. Yeah, the usual thing that you were getting in the editor. And Ken Thompson wrote an editor called QED, which was very, very powerful. But these were all totally a command base. They were not most, or cursor based, because it was before mice and even before cursors, because they were running on terminals that printed on paper. Okay. No CRT type displays, let alone LEDs. And so then when Unix came along, Ken took QED and stripped way, way, way down. And that became an editor that he called ED. That was very simple, but it was a line oriented editor. And so you could load a file. and then you could talk about the lines one through the last line and you could print ranges of lines, you could add text, you could delete text, you could change text, or you could do a substitute command that would change things within a line or within groups of lines.

You know, you're working on any part of it, the whole thing or whatever, but it was entirely command line based and it was entirely on paper paper and that meant that you changed the right real paper and so if you changed the line you had to print that line using up another line of paper to see what change caused okay Yeah. So when when CRT displays came along, then you could start to use cursor control and you could sort of move where you were on the screen without reprinting everything, printing. And there were a number of editors there, the one that I was most familiar with and still use is VI, which was done by Bill Troy. And so that dates from probably the late 70s as a guess. And it took a full advantage of the cursor controls. I suspected e-max was roughly at the same time, but I don't know. I've never internalized e-maxed. So I use, at this point, I stopped using e-d, although I still can. I use vi sometimes. And I use Sam when I can.

It is available. You have to download it yourself from typically the plan line operating system distribution. It's been maintained by people there. And so I'll get home tonight.

I think it's like what religion were you brought up?

So I guess you could say programming languages started probably in what the late 40s or something like that. People used to program computers by basically putting in zeros and ones using something like switches on a console and then or maybe holes and paper tapes, something like that. So extremely tedious awful, whatever. And so I think the first programming languages were relatively crude assembly languages where people would basically write a program that would convert namanics like add ADD into whatever the bit pattern was that corresponded to an add instruction and they would do the clerical work of figuring out where things were so you could put a name on a location in a program and the assembler would figure out where that corresponded to when the thing was all put together and dropped into memory and they Early on, and this would be the late 40s and very early 50s. There were assemblers written for the various machines that people used. You may have seen in the paper just a couple days ago, Tony Burkard died. He did this thing in Manchester called the, called AutoCode, a language which I knew only by name. But it sounds like it was a flavor of assembly language, sort of a little higher in some ways. And it replaced a language that's Alan Turing wrote, which you put in zeros and ones. But you put him in backwards order because that was a hardware work.

So assembly languages, then let's call that the early 1950s. And so every different flavor of computer has its own assembly language. So the ed sack had hits and a Manchester had it and the IBM whatever, 70, 90 or 704 or whatever had hits. And so everybody had their own assembly language.

Right. They have exactly in their simplest form at least one instruction per or one assembly language instruction per instruction in the machine's repertoire. And so you have to know the machine intimately to be able to write programs in it. And if you write in a assembly language program for one kind of machine and then you say, gee, it's nice. I'd like a different machine or start over. Okay. So very bad. And so what happened in the late 50s was people realized you could play this game again and you could move up a level in writing or creating languages that were closer to the way the real people might think about how to write code. And there were, I guess, arguably three or four at that time period. There was Fortran, which came from IBM, which was formula translation meant to make it easy to do scientific and engineering computation.

That's what I stood for. Yeah. I was Cobalt, which is the common business oriented language that I grace Hopper and others worked on, which was aimed at business kinds of tasks. There was a law which was mostly meant to describe algorithmic computations. I guess you could argue basic was in there somewhere. I think it's just a little later. And so all of those moved the level up. And so they were closer to what you and I might think of as we were trying to write a program. And they were focused on different domains for trend for formula translation engineering computations. Let's say, cobalt for business. That kind of thing.

Oh yeah, cobalt too. But the deal was that once you moved up that level then you let's call it 4-tran. You had a language that was not tied to a particular kind of hardware because a different compiler would compile for different kind of hardware. And that meant two things. It meant you only had to write the program once, which was very important. And it meant that you could, in fact, if you were a random engineer, physicist, whatever, you could write that program yourself. You didn't have to hire a programmer to do it for you. It might not be as good as you'd get through a programmer, but it was pretty good. And so it democratized and made much more broadly available, they built it right code.

Yeah, anybody who is willing to invest some time in learning a programming language and is not then tied to a particular kind of computer. And then in the 70s you get system programming languages, which see as the survivor.

that programming languages that would take on the kinds of things that would necessarily write so-called system programs, things like text editors or assemblers or compilers or operating systems themselves, those kinds of things.

It's a different flavor of what they're doing. They're much more in touch with the actual machine in a but in a positive way that is you can talk about memory and a more controlled way. You can talk about the different data types that the machine supports and a way there and more ways to structure and organize data and so the system programming languages there was a lot of effort in that in the call it the late 60s early 70s. See, I think the only real survivor of that. And then what happens after that, you get things like object oriented programming languages because as you write programs in a language like C at some point scale gets to you and it's too hard to keep track of the pieces and there's no guardrails or training wheels or something like that to prevent you from doing bad things. So C++ comes out of that tradition.

I think it found a sweet spot that in of expressiveness, so you could really write things in a pretty natural way and efficiency, which was particularly important when computers were not nearly as powerful as they are today. I've got to put yourself back. 50 years almost in terms of what computers could do. That's roughly four or five generations, decades of Moore's law, right? So expressiveness and efficiency and I don't know, perhaps the environment that it came with as well, which was Unix. So it meant if you wrote a program, it could be used on all those computers that ran Unix, and that was all of those computers, because they were all written in C, and that was Unix, the operating system itself was portable, as were all the tools. So it all worked together again in one of these things where things fed on each other in a positive cycle.

No, of course not.

A lot of it is, it's clearly, timing was good. Now Dennis and I wrote the book in 1977. I'm not scratching. Yeah, right. And at that point, UNIX was starting to spread. I don't know how many there were, but it would be dozens to hundreds of UNIX systems. And C was also available on other kinds of computers that had nothing to do with UNIX. And so the language made some potential. And there were no other books on seed. And Bell Labs was really the only source for it. And Dennis, of course, was authoritative because it was his language. And he had written the reference manual, which is a marvelous example of how to write a reference manual really, really, very, very well done. So I twist to design until he agreed to write a book. And then we wrote a book. And the virtue or advantage, at least, I guess, of going first is that then other people have to follow you if they're going to do anything. And I think it worked well because Dennis was a per brighter. I mean, he really, really did. And the reference manual in that book is his period. I had nothing to do with that at all. So just crystal clear prose, very well expressed. And then he and I wrote most of the expository material. And then he and I sort of did the usual ping-ponging back and forth. refining it. But I spent a lot of time trying to find examples that would sort of hang together and that would tell people what they might need to know about the right time that they should be thinking about needing it. And I'm not sure it completely succeeded, but it mostly worked out fairly well.

A good example will tell you how to do something, and it will be representative of, you might not want to do exactly that, but you will want to do something that's at least in that same general vein. And so a lot of the examples in the C-book were picked for these very, very simple straightforward text processing problems that were typical of Unix. I want to read input and write it out again. There's a copy command. I want to read input and do something to it and write it out again. There's a graph. And so that kind of fine things that are representative of what people want to do and spell those out so that they can then take those and see the the core parts and modify them to their taste. And I think that a lot of programming books that I don't look at programming books, a tremendous amount these days, but when I do, a lot of don't do that. They don't give you examples that are both realistic and something you might want to do. Some of them are pure syntax. Here's how you add three numbers. Well, come on, I could figure that out. Tell me how I would get those three numbers into the computer and how it would do something useful with them. And then how I put them back out again, deeply formatted.

Yeah, right. And I think it's the attempt, and it's absolutely not perfect. But the attempt in all cases was to get something that was going to be either directly useful or would be very representative of useful things that a programmer might want to do. But within that vein of fundamentally text processing, reading text, doing something, writing text.

Not you're missing something.

So I think, so Go! Go first comes from that same Bell Labs tradition in part, not exclusively, but two of the three creators can Thompson and Rob liked.

And then with this very, very useful influence from the European school in particular, the close spirit, influence through Robert Grismer. There was, I guess, a second generation down. student at ETH. And so that's an interesting combination of things. And so some ways go captures the good parts of C. It looks sort of like C. It's sometimes characterized as C for the 21st century. On the surface it looks very, very much like C. But at the same time, it has some interesting data structuring capabilities. And then I think the part that I would say is particularly useful. And again, I'm not a go expert in spite of co-authoring the book about 90% of the work was done by Alan Donovan, my co-author, who is a go expert. But Go provides a very nice model of concurrency. It's basically the cooperating communicating sequential processes that Tony Hart set forth, I don't know, 40 plus years ago. And Go routines are to my mind, a very natural way to talk about parallel computation. And then the few experiments I've done with them, they're easy to write. And typically, it's going to work and very efficient as well. So I think that's one place where Go stands out, took that model of parallel computation. It's very, very easy and nice to go with.

I would guess not really. I mean, maybe it was seen but not at the level where it was something you had to do anything about. For a long time, processors got faster. And then processors stop getting faster because of things like power consumption and heat generation. And so what happened instead was that instead of processors getting faster, they started to be more of them. And that's where that parallel thread stuff comes in.

It's not break my heart, but I would love to be able to try more of these languages. The closest I've come is in class that I often teach in the spring here. It's a programming class. And I often give, I have one sort of small example that I will write in as many languages as I possibly can. I've got it in 20 languages at this point. and and that's so I do a minimal experiment with a language just to say okay I have this trivial task which I understand the task and it should it takes 15 lines in arc and not much more in a variety of other languages so how big is it how fast is it running what pain did I go through to learn how to do it and that's a It's like anecdote, right? It's a very, very narrowly simple data.

Yeah, and some of my experience with some languages is very positive, like Luah, a scripting language I had you never used. And I took my, little permanent. The program is a trivial format or it just takes in lines of text of varying lengths and it puts them out in lines that have no more than 60 characters on each line. So think of it's just kind of the flow process in a browser or something. So it's very short program. And in Lua, I downloaded Lua in an hour ahead of working, never having written Lua in my life. just going with on-light documentation. I did the same thing in Scala which you can think of as a flavor of Java equally trivial. I did it in Haskell. It took me several weeks. But it did run like a turtle. And I did it in Fortran 90 and it Wow. Painful, but it worked. And I tried it in Rust, and it took me several days to get it working, because the model of memory management was just a little unfamiliar to me. And the problem I had with Rust is back to what we were just talking about. I couldn't find good consistent documentation on Rust. Now, this was several years ago, and I'm sure things have stabilized. But at the time, everything in the Rust world seemed to be changing rapidly. And so you would find what looked like a working example, and it wouldn't work with the version of the language that I had. So it took longer than it should have. Rust is a language I would like to get back to, but probably won't. I think one of the issues you have to have something you want to do. And if you don't have something that is the right combination, if I want to do it, and yet I have enough disposable time, whatever, to make it worth learning a new language at the same time, it's never going to happen.

Yeah. Well, I think you Captured in a lot of ways, when it first came out, JavaScript was deemed to be fairly irregular and an ugly language. Certainly in the Academy, if you said you were in JavaScript, people would ridicule you. It was just not fit for academics to work on. I think a lot of that has evolved the language itself has evolved and certainly the technology of compiling it is fantastically better than it was. And so in that sense, it's absolutely a viable solution on backends as well. It's the front end used well. I think it's a pretty good language. I've written a modest amount of it and I've played with JavaScript translators and things like that. I'm not a real expert and it's hard to keep up even there with the new things that come along with it. So, I don't know whether it will ever take over the world, I think not, but it's certainly an important language and we're just knowing more about it.

Yeah, that's a very perceptive kind of question. One of the reasons programming was fun in the old days was that you were really building it all yourself. The number of libraries you had to deal with was quite small, maybe it was print out for the standard library or something like that. And that is not the case today. And if you want to do something you mentioned Python and JavaScript and those are the two funny examples you have to typically download a boatload of other stuff and you have no idea what you're getting. Absolutely nothing. I've been doing some playing with machine learning over the last couple of days, and Gee, something doesn't work. Well, you pip install this, okay, and down comes another gazillion megabytes of something, and you have no idea what it was. And if you're lucky, it works. And if it doesn't work, you have no recourse. There's absolutely no way you could figure out which in these thousand different packages. And I think it's worse in the MPM environment for JavaScript. I think there's less discipline, less controller.

probably not.

I certainly don't hope it. I'm not sure that that's right because I honestly don't think there is one language that will suffice for all the programming needs of the world. are there too many at this point? Well, arguably, but I think if you look at the distribution of how they are used, something called a dozen languages that probably account for 95% of all programming at this point and that doesn't seem unreasonable. And then there's another well 2000 languages that are still in use that nobody uses and or at least don't use in any quantity. But I think new languages are good idea in many respects because they're often a chance to explore an idea of how a language might help. I think that's one of the positive things about functional languages, for example, they're a particularly good place where people have explored ideas that at the time didn't seem feasible, but ultimately have wound up as part of mainstream languages as well. I mean, you just go back as early as recursion, list, and then follow forward functions as first class citizens and pattern based language is and gee, I don't know, uh, closures and just on and on and on. Lambda's interesting ideas that showed up first in let's call it broadly the functional programming community and then find their way into mainstream languages.

And so I think the languages in the playground themselves are probably not going to be the mainstream, at least for some while, but the ideas that come from their are invaluable.

Sure, so ample is a language for mathematical programming, technical term, think of it as linear programming. That is setting up systems of linear equations that are, yeah, of some sort of system of constraints, so that you have a bunch of things that have to be less than this greater than that, whatever, and you're trying to find a set of values for some decision variables. that will maximize or minimize some objective function. So it's a way of solving a particular kind of optimization problem, a very formal sort of optimization problem, but one that's exceptionally useful.

So I preface it by saying I'm absolutely not an expert on this and most of the important work in ample comes from why two partners in crime on that Bob Forer who was a professor of and in the Industrial Engineering and Management Science Department at Northwestern and my colleague at Bellab's Dave Gay who was a numerical analyst and optimization person. So the deal is linear programming. Let's say the linear program is the simplest example of this. So linear program is taught in school is that you have a big matrix, which is always called A and you say Ax is less than or equal to B. So B is a set of constraints, X is the decision variables, and A is the how the decision variable are combined to set up the various constraints. So A is a matrix and x and B are vectors. And then there's an objective function which is just to sum of a bunch of x's and some coefficients on them and yet that's the thing you want to optimize. The problem is that in the real world that matrix A is a very, very, very intricate, very large and very sparse matrix where the various components of the model are distributed among coefficients in a way that is totally unobvious to anybody. And so what you need is some way to express the original model, which you and I would write, you know, we'd write mathematics on the board. And the sum of this is greater than the sum of that kind of thing. So you need a language to write those kinds of constraints. And Bob Forer from long time had been interested in modeling languages, languages that made it possible to do this. There was a modeling language around called Gams, the general algebraic modeling system. But it looked very much like Fortran, which was kind of clunky. And so Bob spent a sabbatical year at Bell Labs in 1984 and he and was in the office across from me and it's always geography and he and Dave Gayne and I started talking about this kind of thing. And he wanted to design a language that would make it so that you could take these algebraic specifications, you know, summation signs over sets, and that you would write on the board and convert them into basically this A matrix. And then pass that off to a solver, which is an entirely separate thing. And so we talked about the design of the language. I don't remember any of the details of this. Now, but it's kind of an obvious thing. You're just writing a mathematical expressions in a fortune, like, sorry, an algebraic, but textual language. And I wrote the first version of this ample program, my first C++ program.

And so I did that fairly quickly. We wrote, it was, you know, 3,000 lines or something, so it wasn't very big. But it just sort of showed the feasibility of it that you could actually do something that was easy for people to specify. models and converted into something that is solver could work with. At the same time, as you say, the model and the data are separate things. So one model would then work with all kinds of different data in the same way. Lots of programs do the same thing, but with different data.

It's not too bad because most of the solvers have some mechanism that lets them import a model in a form. It might be as simple as the matrix itself in just some representation. Or if you're doing things that are not linear programming, then there may be some mechanism that lets you provide things like functions to be called or other constraints on the model. So all ample does is to generate that kind of thing and then solver deals with all the hard work and then when the solver comes back with numbers, ample converts those back into your original forms. So you know how much of each thing you should be buying or making or shipping or whatever. So we did that in 84 and I haven't had a lot to do with it. Since except that we wrote a couple of versions of a book on it, which is one of the greatest books ever written.

It's an excellent book, Bob for a wrote most of it. And so it's really, really well done. He must've been a dynamite teacher.

No, no, no. Are you kidding?

Yeah. I think a T-Rough is a a predecessor to the tech family of things. It's a format that was done at the labs in this same period of the very early 70s. All that predates tech and things like that play five to ten years.

The answer is no, although I told that somebody asked a Jeff Dean if that was under what conditions P would equal in P, and he said either P is zero or N is one. Or vice versa, I forgot.

I have no intuition, but I've got a lot of colleagues who've got intuition, and they're betting is no.

I don't do that stuff. The last time I touched anything to do with that, which many years ago was before it was invented. It's literally true. I did my PhD thesis on graph. I did this in 1968 and I worked on graph partitioning, which is this question. You've got a graph that is a nodes and edges kind of graph and the edges have weights and you just want to divide the nodes into two piles of equal size so that the number of edges that goes from one side to the other is as small as possible.

Well, as it turns out, I worked with Shen Lin at Bell Labs on this, and we were never able to come up with anything that was guaranteed to give the right answer. We came up with heuristics that worked pretty darn well, and I peeled off some special cases for my thesis, but it was just hard. And that was just about the time that Steve Cook was showing that there were classes of problems that appeared to be really hard of which graph partitioning was one. But this my expertise such as it was totally predates that development.

You were trying to find something that did the job, and there was nothing that you would call, let's say, a closed form or algorithmic thing that would give you a guaranteed right answer. I mean, compare graph partitioning to max flowmen cut or something like that. That's the same problem, except there's no constraint on the number of nodes on one side or the other of the cut. And that means it's an easy problem. at least as I understand it, whereas the constraint that says the two have to be constrained and size makes it a hard problem.

I don't know. I mean, certainly in all seriousness, I just didn't have the talent for it. When I got here as a grad student, Princeton, and I started to think about research at the end of my final first year or something like that, I worked briefly with John Hopcroft who was absolutely, you know, you mentioned during a word winner, it said, a great guy and it became crystal clear. I was not cut out for this stuff period. Okay. And so I moved into things where I was more cut out for it and that tended to be things like writing programs and then ultimately writing books.

I think that was one of the, well, you've heard of AI winners. This is whatever the opposite was. AI summer or something. It was one of these things where people thought that, boy, we could do anything with computers that all these hard problems we could computers will solve, and they will do machine translation, they will play games like chess, that they will do missions, you know, prove theorems in geometry. There are all kinds of examples like that where people thought, boy, we could really do those sorts of things. And, you know, I read the cool aid and sometimes I still have a wonderful collection of papers called Computers and Thought that was published in a boat that era and people were very optimistic. And then of course it turned out that what people thought was just a few years down the pike was more than a few years down the pike. And some parts of that are more or less now sort of under control. We finally do play games like go and chess and so on better than than people do, but their others on machine translation is a lot better than it used to be, but that's 50 close to 60 years of progress and a lot of evolution in hardware and a tremendous amount more data upon which you can build systems that actually can learn from some of that.

Well, I guess the lesson is that in the short run, it's pretty easy to be too pessimistic or maybe too optimistic and in the long run, you probably shouldn't be too pessimistic. I'm not saying that very well. It reminds me of this remark from Arthur Clark, his science fiction author, who says, you know, when some distinguished bed elderly person says that something is him, is possible. He's probably right. And if he says it's impossible, he's almost surely wrong. But you don't know what the time scale is.

I think it's very interesting. I am incredibly far from an expert. Most of what I know I've learned from my students and they're probably disappointed in how little life learned from them. But I think it has tremendous potential for certain kinds of things. The games is one where it obviously has had effect on some of the others as well. I think there's, and this is speaking from definitely not expertise. I think there are serious problems in certain kinds of machine learning, at least because what they're learning from is the data that we give them. And if the data we give them has something wrong with it, then what they learn from it is probably wrong too. And the obvious thing is some kind of bias in the data. The data has stuff in it like I don't know. Women earned is good at men as man at something, okay? That's just flat wrong. But if it's in the data because of historical treatment, then that machine learning stuff will propagate that and that is a serious

Yeah, that's an optimistic point of view. And if it works that way, that would be absolutely great. And what I don't know is whether it does work that way or whether the AI mechanisms or machine learning mechanisms reinforce an amplify things that have been wrong in the past. And I don't know, but I think that's a serious thing that we have to be concerned about.

I haven't a clue and I don't know.

I mean, Turing talked about this and it is paper on machine intelligence back. And she's on early 50s or something like that. And he had the idea of the Turing test. And I don't know what the Turing test is. Is a good test of intelligence. I don't know. It's an interesting test. At least it's in some vague sense objective whether you can read anything into the conclusions as a different story.

It's some combination of those. I think Almost all technologies over the long run are for good, but there's plenty of examples where they haven't been good either over a long run for some people or over a short run and computing is one of those and AI within it is going to be one of those as well, but computing broadly, I'm just a today example, this privacy. that the use of things like social media and so on means that and the commercial surveillance means that there's an enormous amount more known about us by people, other businesses government, whatever, than perhaps one ought to feel comfortable with. So that's an example.

Well, the frivolous answer is no exponential and go on forever.

Yeah, right, what matter does? So I don't know. We've seen places where Moore's law has changed. For example, mentioned earlier, processors don't get faster anymore, but you use that same growth of, you know, building, put more things in a given area to grow them horizontally instead of vertically as it were. So you can get more and more processors or memory or whatever on the same chip. Is that going to run into a limitation presumably? Because, you know, at some point you get down to the individual atoms. And so you've got to find some way around that. Will we find some way around that? I don't know. I just said that if I say it won't, I'll be wrong.

I don't worry about that. I think what will happen is continuation of what we see in some areas at least which is that more programming will be done by programs than by people and that more will be done by sort of declarative rather than procedural mechanisms where I say I want this to happen you figure out how and that is in many cases at this point domain of specialized languages for narrow domains but you can imagine that broadening out. And so I don't have to say so much in so much detail. Some collection of software, what's called it, languages or programs or something, will figure out how to do what I wanted to.

Yeah. Well, I can recommend the good book. What's that? The book I wrote for the course. I think this is one of these questions of should everybody know how to program. And I think the answer is probably not, but I think everybody should at least understand sort of what it is so that if you say to somebody, I'm a programmer, they have a notion of what that might be, or if you say this is a program, or this was decided by a computer running a program that they have some They, intuitive understanding and accurate understanding of what that might imply. So part of what I'm doing in this course, which is very definitely for non-technical people and in typical person in it is a history or English major. Try and explain how computers work, how they do their thing, what programming is, how you write a program, and how computers talk to each other, and what do they do when they're talking to each other. I would say nobody very rarely does anybody in that course go on to become a real serious programmer, but at least they've got a somewhat better idea of what all this stuff is about, not just the programming, but the technology behind computers and communications.

Oh yeah, yeah, very small amount. I introduced them to how machines work at a level below high level language. So we have a kind of a toy machine that has a very small repertoire. It doesn't instructions and they write trivial assembly language program. Is that it?

I mean in some sense there's no such thing as the lowest level because you can keep going down but that's the place where I drew the line. So the idea that computers have a fairly small repertoire of very simple instructions that they can do like I had in subtract and branch and so on as you mentioned earlier. And that you can write code at that level and it will get things done. And then you have the levels of abstraction that we get with higher level languages like Fortran or Seer, whatever. And that makes it easier to write the code and less dependent on particular architectures. And then we talk about a lot of the different kinds of programs that they use all the time that they don't probably realize our programs like they're running Mac OS on their computers or maybe Windows and their downloading apps on their phones and all of those things are programs that are just what we just talked about except at a grand scale.

Yeah, right. And so in a way, I'm expecting them to make any enormous conceptual leap from their five or ten line toy assembly language, I think that adds two or three numbers to something that is a browser on their phone or whatever, but it's really the same thing.

Well, I think computing has changed its renders amount, obviously, but I think one aspect of that is the way that people interact with each other, both locally and far away. And when I was, you know, the age of those kids making a phone call to somewhere was a big deal because it cost serious money. And this was in the sixties, right? And today, people don't make phone calls, they send texts or something like that. So if there's up and down in what people do, people think nothing of having correspondence, regular meetings, video, whatever with friends or family or whatever in any other part of the world. And they don't think about that at all. And so that's just the communication aspect of it.

I think it depends a lot on all kinds of things. So I trade mail with my brother and sister in Canada much more often than I used to talk to them on the phone. So probably every two or three days, I get something or send something to them. Whereas 20 years ago, I probably wouldn't have talked to them on the phone nearly as much. So in that sense, I brought my brother and sister and I closer together. That's a good thing. I watch the kids on campus and they're mostly walking around with their heads down fooling with their phones to the point where I have to duck them. I don't know that that has brought them closer together in some ways. sociological research that says people are in fact not as close together as they used to be I don't know where that's really true but but I can see potential downsides and kids where you think come on wake up in the smell of coffee or whatever

It's mixed if the truth be told. I mean, I think there are some things about that that are good. I think there's the potential for people to improve their lives all over the place and that's obviously good. And at the same time, at least in the short time, short run, you can see lots and lots of bad as people become more tribalistic or peroculum in their interests and is an enormous amount more us and them. and people are using computers in all kinds of ways to mislead or misrepresent or flat out live at what's going on and that is affecting politics locally and I think everywhere in the world.

No, he's indeed.

I don't think specific moments. I think there were lots and lots and lots of good times at Bell Labs where you would build something and it worked. I just say worked. So the moments that we used it. Yeah, and somebody used it and they said, gee, that's neat. Those kinds of things happened. quite often in that sort of golden era and that the 70s when Unix was young and there was all this low hanging fruit and interesting things to work on a group of people who kind of we were all together in this and if you did something they would try it out for you. And I think that was in some sense, a really, really good time.

And all your stupid mistakes are right there for them to look at.

Okay, my pleasure. Good fun.