Brian Kernighan: Inside Bell Labs, The Best Programmer, Why C Won

0:00And so in three weeks, he builds himself an editor and assembler and an operating system. And there you have it. By himself? Yeah. Oh, yeah, absolutely. This is Brian Kernaghan, ex-Bell Labs technical staff, co-author of the original C-Book, and the man who popularized Hello World. And I asked him all about what it was like working there. There were no deadlines. There were no projects. There were no objectives, goals, whatever set by other people. There was a secrets file that was committed to the repo. And so you and all your colleagues' passwords are actually... Yeah. So I saw yours is... Do you believe that LLMs are net negative or net positive? So who shall I insult today? Here's the full episode.

0:54Could you explain what Bell Labs was and what is the story behind you getting a job there? So Bell Labs was like the research arm of AT&T. It was founded in, I think, 1923, 25, something like that. AT&T at that point was growing and it absorbed a bunch of the local telephone companies across the whole country. And they realized that they just needed to understand things better so that they could improve service. So they set up a research operation, which was called Bell Telephone Laboratories. It was in New York on West Street. And people did all kinds of things related to improving telephony. In 19, is it in, call it 63, something like that, early sixties, they basically moved the whole operation to New Jersey, Northern New Jersey, a

1:44place called Murray Hill, which near Summit and things like that. So call it 25 miles west of New York City. And that was a big operation. There were probably 3,000 people in one connected set of buildings doing research in all kinds of things, physics, semiconductor physics, devices like that, chemistry, optical fiber kinds of things, just all sorts of research. And then more on the soft end, there was mathematics. And increasingly, there was computers, computer-related things as they gradually came to the realization that computing was going to be part of the future in some way or another. In the summer of 1966, I was a grad student here at Princeton. I got an internship at MIT in Cambridge working in Project Mac,

2:36which was basically the Multics project. And so I used CTSS, that first original time-sharing system done by Corby and friends, to develop software for the Multics system, which was just starting up. And that was a lot of fun. I enjoyed it. I'm not sure I ever did anything that was very useful, but part of it was then the next year I got an internship at Bell Labs in Murray Hill. So I was still a graduate student and that would be roughly the third year here. I got this internship at Bell Labs and that was a lot of fun. And I worked there. I worked actually with Doug McElroy for the summer, came back here, continued to stall on doing my thesis work, which I guess is what one does. And then I got another internship in the summer in 1968.

3:40And there I worked with Shen Lin and he and I worked on a problem which had been suggested by my advisor here. And this was graph partitioning. And he and I worked on it and we came up with an algorithm that did a pretty decent job on part of it. I came up with several special cases that you could do really well. And then I wrote up the thesis really quickly and escaped. Escaped from Princeton. I took a whole week off and went to Bell Labs because they'd given me a return offer, which was very sweet of them. And I stayed there then until roughly 2000 in the group that had done or was doing a variety of things. Did you consider other career opportunities at the time? I think I didn't consider any other option whatsoever.

4:23I mean, I had really enjoyed the summers. The two summers were great. The people were really, really nice and interesting. There was stuff to do. It was close. I didn't have to go anywhere, as it were. And so I literally never considered anything else. I never had a job interview. Nothing like that. I just went there. So it was kind of like falling down the fall line, nothing like that. I just went there. So it was kind of like falling down the fall line or something like that. I think partly it was helped along by some sort of old boy network where somebody here at Princeton knew somebody at Bell Labs because there's a lot of back and forth between the two institutions. And so I'm sure that that kind of thing helped. It also helped, I think, at MIT that a guy who had had an internship the year before me had done a bang up job for them.

5:13And so that probably said, well, these folks from Princeton are maybe OK. So I'm grateful to him, too. Nowadays, Bell Labs is so legendary that at that time, what was the social perception? If I were to have talked to your peers and said, hey, what do you think of Bell Labs? What would they have said at that time? I suspect that it depended on the field, but probably for most of them, they would have thought, yeah, yeah, this is a really good place because in the physical sciences, it was obviously the powerhouse in a lot of respects. That's where your transistor came from, for examplehouse in a lot of respects. That's where your transistor came from, for example. And a lot of things related to communications, that's where information theory

5:51came from. That's where error correcting codes came from. All these things that were sort of critical advances in technology had come from Bell Labs. Bell Labs was a part of the scientific community. People who went to Bell Labs published in exactly the same journals and went to the same conferences, collaborated with people in the same universities. And so it was really an integral part, I think, of the scientific community at the time. And that was largely, I will say, the physical sciences kind of thing. But it obviously sort of spread out into other things that were peripherally related. And certainly the mathematicians were absolutely first rate as well. Tended to be applied mathematicians rather than theoretical ones.

6:35Everything you just said there is an insane value for humanity, the transistor, and all of those other things. Why is it that so much of it came from one research lab tied to a company that today is not known for all these amazing innovations? AT&T bankrolled all kinds of contributions that Bell Labs made. And I think the way it worked was that AT&T provided telephone service to essentially the whole country. I mean, maybe it was 80%, but it was a very substantial fraction of all country. And that meant that they had a pretty guaranteed revenue stream. Now, it was regulated. They were a regulated public monopoly. That's the jargon term. And that meant that their rates were set or restricted or at least evaluated by lots and

7:27lots of agency states and the federal government. So there was a limit to what they could do. The quid pro quo was they got sort of a guaranteed rate of return on their investment in whatever they did with the phone company. And the quid pro quo would be that they provided telephone service to essentially everybody. Even if you were way out in the boonies quo would be that they provided telephone service to essentially everybody. Even if you were way out in the boonies or something like that, AT&T would provide the service. And they were able to rip off a small fraction that I will make up a number and say one or 2% of their pretty much guaranteed revenues to fund a research operation that would let them improve the service.

8:08And so that was the basic, call it financial arrangement. And the other thing is it was very stable. You could sort of predict there would be this steady increase in revenues, but predictable in a way that would guarantee that there would always be money to do something. There was no competition because AT&T had essentially what amounted to this monopoly. And so that meant that they could take a very long view of what they were doing. And so if somebody had an idea and wanted to work on it for a year or two or three, fine, go for it. And if you've got a bunch of people doing this, even if your idea is dumb, my idea is dumb, somebody else might have a good idea. And so if you aggregate that, the output would be probably something useful almost all the

8:52time. What gave this lab such recruiting pull, in your opinion? How are all the best people coming to this place? Well, I think it depends. For me, it was certainly happenstance, just blind luck, being in the right place at the right time, following people who had done something that in some way prepared them way. I think if you were a physicist getting your degree in physics, pick your favorite good university, where would you go to do physics? Well, the opportunities would fundamentally be government lab, perhaps, or a place like maybe IBM or maybe Bell Labs. And Bell Labs had a sterling reputation, well-earned, for doing exceptional work in that area. So that would be, let's say, anybody doing physics, chemistry, materials, all of that kind of stuff.

9:53I think somewhat the same would be true of anything related to mathematics, especially the mathematics of communication or anything related to communication systems. That's where Shannon was. That's where Hamming was. Bode, Nyquist, all those people before those. So that, again, tremendous reputation for the place. And as I said, they were part of the scientific community. It wasn't like it was off in Mars and where, and it wasn't like you went there and disappeared. You went there and you were a part of the broader community. And so I think the computing stuff came along and had some of the same advantages, but it wasn't clear who the heroes were at that point. It was early-ish because remember I was, I went there in 1969.

10:27So this was, computers were still pretty young at that point. A lot of those names you mentioned, I mean, they were in my, you know, textbooks when I was studying. And so they're kind of the heroes and everything. But so at that time you're saying your perspective was they were just kind of the lead on the team, but they weren't the legendary computer scientists. Well, it's hard to say, and it's not even clear what a computer scientist is, but you want a story. When I went to Bell Labs for my first internship, so call it the summer of 1967, and I was in an office that was sort of a little smaller than the one we're sitting in now. But as a summer intern, for some accidental reason, I had an office of my own.

11:12This never happens, but it did happen. And so I'm sitting there in the very first day at about, you know, roughly 11 o'clock in the morning, wondering what the hell do I do? And this older guy came along, passed the door and he said, hi, I'm Dick. Let's go to lunch. I said, okay. So I went to lunch with Dick. I never did get his name right. And so we had a nice lunch conversation. I don't remember anything about it. And then he went off somewhere else and I came back and I went the next door to me and looked at the name tag on the door. It was Dick Hamming. Hamming had written the book that I had used previous semester for numerical analysis and, of course, error correcting codes. And there he was next door, super nice guy.

11:59And was he a computer scientist? Borderline, but possibly he did win the third Turing Award. Won it, was it that summer or the next summer? I'd have to go and look. And so there were people like that around, but in the very early days, the computing stuff was, I think, it hadn't developed into something with its own academic structure, its own reward systems, and all those kinds of things. When I interviewed Leslie Lamport, and I forgot his exact timelines, but I remember early in his education, computer science wasn't established. And he actually said it was not as respected as math and physics, or maybe because it just was a burgeoning. That's brand new. The same thing happened here, I think.

12:49I came here as a grad student in 1964 and I came in electrical engineering. I had thought to work on computing because I had some notion that it was interesting and I thought AI. I didn't go think. That's unbelievably naive. And I had sought to work with a guy named Arthur Samuels, who had done some interesting stuff in computer chess playing. And I got here, discovered it was the wrong guy. But when I got here, the electrical engineering department had a bunch of very established, highly respected people who were doing traditional electrical engineering things, information theory, communications, solid state physics, that kind of stuff. And a cohort of young people who had interest in computing.

13:35They had just gotten their degrees from someplace and they were very young and wanted to do computing. And I don't know whether any of them ever got tenure because the older folks didn't really grok the newer field. John Hopcroft, to pick a random example, was my technical advisor for a year. Although it was quickly discovered I was not a theoretician. But, you know, John went on to win a Turing Award and was dean of engineering at Cornell. He's just a great guy. But he wouldn't have gotten tenure here at that particular time because the computing science aspect of things was too new. Bell Labs is kind of famous for very hands-off management and letting the engineers kind of do what they were doing.

14:30What is a day in the life like of an engineer working at Bell Labs? Well, first thing, I don't think any of us would have called ourselves engineers. We were doing whatever we did, but I don't think that engineer was the right word because we weren't really engineering. It was member of technical staff. Member of technical staff, which was a term that applied to everybody, essentially. And a typical day would be basically you'd come in at whatever time, which could be anywhere from, you know, eight in the morning to two or three in the afternoon, maybe. And you would sit in your office, private office, with the door open, and you would think about whatever it was you were thinking about. Maybe

15:12you had been working on some kind of program, or maybe you were trying to prove a theorem. That's not me. And people would wander by, and you would talk to them. They would come in. You'd have discussions on a blackboard, perhaps of technical things, or maybe just arm-waving discussions of something else. You'd walk up and down the very long main corridor to the coffee machine at the other end, you would run into random people. There would be technical talks from time to time, maybe one every week to something like that, depending sometimes from internal people, sometimes from external people. So in a sense, maybe not too different from what you would find in a university, except there were no students.

15:54And so that meant you could do it full time. The tradeoff was that without the students, you could do more of your own thing and you were doing it with your peers. So, you know, I would argue with somebody, Ken Thompson or Dennis Ritchie or whatever like that, who were my peers. I didn't have to work with students, but of course the flip side is that I didn't get any of the benefit that you'd get with bright, young, new people talking about it, except that as a newcomer, they're always supposedly the bright new young person. So mainly the lack of students, which I think is a mixed blessing. In industry, there's often deadlines and managers and all of that stuff, right? What's stopping a researcher from coming in at three, leaving at five, not having any output?

16:52There was no immediate stop to that period. There were no deadlines. There were no projects. There were no objectives, goals, whatever set by other people. The mechanism for deciding whether you were doing anything was that once a year, you had to write down on one side of one piece of paper what you had done. And we called it the I Am Great Report. And it just summarized what you'd done. And then the first and second level of management would sit in a room with the I Am Great Reports from their people. So this would be maybe 30 at the bottom, half a dozen, one like that little tree. And they would discuss the merit of the contributions of the work that was being done by the people. And they would come up with some sort of ordering which says you're better than I am or vice versa.

17:40How would we compare to our peers? And that would give them a sort of roughly a rank order, or at least equivalence classes of people. And if somebody hadn't done anything for a couple of years, that would be noticed. But if somebody had gone off on something and it didn't pay off very well, or it was still in progress, but it was okay or whatever, that was okay. That's the long view that I mentioned before. It's not like, what have you done for us the last week or even quarter? What maybe have you done over the last two, three years? And it was being assessed by people who were not driven by quarterly numbers. They were the same people as we were, except that they had moved into management, but they

18:21were still technically active and they were very technically knowledgeable. And then the process was repeated a couple of levels up until they had any effect or rank order and they've everybody. So that was kind of that called abstract merit. No, you know, I'm better than you are. And then there was the concrete merit phase where we got this much money. How much do you get? How much do I get? So there were bonuses or tied to. It wasn't bonuses or anything like that. It was simply there's a pot of money. This is the raise pool and it will be overall X percent. And so you will get X minus epsilon. I'll get X plus epsilon or vice versa. Oh, and that was once a year. And that was the whole story.

19:03But it was it was very deliberative. The management was collegial. If you and I were managers and we had our people, it wasn't like my people are better than your people. It's rather, hey, you forgot to mention that, you know, Susie did this really great thing. Don't forget Susie kind of thing. So it was quite collegial. And you would be evaluated by people who understood the work and whose goals and aspirations and so on were the same as yours, you know, do good stuff. It sounds like you mentioned that their technical is like a big part of this whole system. Why is that important? If somebody is doing something in a technical area, they have created a new program, they've proved a new theorem, they've developed a new process, whatever.

19:48If you are not technical enough to understand what they're talking about, it's hard for you to tell the bullshit from the actual useful content, right? So I could, not you personally, but I could blow smoke pretty well for people who were, I don't know, who shall I insult? MBAs. Okay. Something like that. That's obviously a slander, but it's easier to blow smoke at somebody who is not sort of knowledgeable in your own field. But the people who were evaluating your work were exceptionally knowledgeable in the whole field. And so they had a pretty good eye for what was good stuff and what wasn't yet good stuff or would perhaps never be good stuff. These days, this member of technical staff title, it almost has its own brand where it's

20:42a nod towards Bell Labs and everything that that represented there. But a lot of what it is signaling is that titles don't matter, that we're all the same, and we're all just focused on the technical work. Did titles matter, or what was the culture at that time? Titles didn't matter. Everybody was on a first-name basis. There were no doctor, professor, whatever kind of titles at all. Everybody was technically a member of staff, member of technical staff. And I say everybody, this is of course an oversimplification. There were a variety of supporting people who, you know, lab technicians, associate members of technical staff or whatever. But I'm talking about the MTS level. And so they would be loosely equivalent to PIs associate members of technical staff or whatever, but I'm talking about the MTS level.

21:32So they would be loosely equivalent to PIs in the modern academic role, principal investigator, whatever. And in computing, I would never have had somebody who helped me with my stuff. Whereas if I were a physicist, I might have some number of people who would help me do experiments, look after the mechanics of depositing stuff on stuff, all those kinds of things that land in a physical world. But everybody was technically a member of technical staff in the management, but then there were department heads who'd manage first level management. And then there were directors who were second level management. And then there was executive director. And then there were directors who were second level management. And then there was executive director.

22:08And then there was vice president. But it was very flat in that sense. Most people did not want to be promoted because that would be seen as the end of their personal technical career. It would move them away from the kind of work that they really enjoyed doing. So being promoted was something to be avoided, not to be sought. And I think that went for quite a long time. You know, things did change, but I'm talking about the golden era of, call it the late 60s, 70s, early 80s, something like that. Did you and your peers ever think about the notion of career development in some way, or it was not even something you cared about? Career development for myself as an individual, I never thought about it at all. I mean, I was having a good time and I

22:57was surrounded by lots of good people. Career development for the people, for example, when I was in first level management, I was a department head for some years. I don't remember much about how explicit it was, but there was some theory that you should actually be looking after the interests of the people in your department. I think the main way that that would be reflected is understanding the work they were doing, really trying to understand what it was they were doing so that you could represent it fairly at things like merit review. Also, so you could see opportunities to, you know, oh, gee, did you know Dave was working on this stuff? So that you could sort of cross-fertilize across the way

23:39to try and give them feedback. So to say, you know, are you sure this is going to work? Or keep an eye on this, sort of guide them towards future success, but not telling them what to do. There was never any, this is what you have to do. There was no, no, there just wasn't any, it wasn't guidance at all. At most, there was a gentle gravitational pull towards stuff that would be useful or interesting. So you mentioned you were ahead at some point and you managed some reports. You never had a report that was saying, I want to grow in some way or they're kind of hustling, you know, kind of pushing you some way. There were a handful of people I could remember who wanted to be in management. Okay. That was unusual, but there

24:25was nothing wrong with it. It's just that being in research management, because the structure was so flat that it would take probably quite a while before you would move up. If you really wanted to be in management, you probably wanted to move into a different organization, development organization, where the rules of engagement and so on were much different. And there were several, I shouldn't say several, but at least a handful of people who were interested in that kind of advancement. And they went into development type jobs, which are perfectly fine, just different in a lot of ways. And there they had the much more traditional responsibilities of management and including looking after their people. But I think the research operation was

25:10much more a bunch of cats and you can't really herd them. So what's the story behind you becoming a manager in that kind of environment? Because it seems like it's something everyone's avoiding. I had no desire to do it. And I was blandished a couple of times. Wouldn't you like to be a manager? But it was in some other organization, even within research. And I always thought the group that I was in was special. Well, there was. And so I had no interest in being manager in some other part of it. And so I basically declined with thanks. But then it was, would you like to be a manager in your own organization? And I wasn't very enthusiastic, but okay. And they got lots of ways they can, you know, it's inevitable. Why not now?

26:00Or alternately, you know, if you don't do it now, it might never come. Would you be completely contradicted? Or if you don't do it, somebody else not as good is going to do it. You know, so all of the usual stuff. And I finally succumbed, I think, in about 81. So I'd been there at that point, call it 12 years for real. So that's the first promotion. And it was okay, but it wasn't as much fun, I think, because now I was responsible for roughly 10 people, had to understand their work, which was all over the map, had to be able to talk to other people about it, had to go to more meetings. So it was okay, but it was not my favorite part of the job, really. How did you know your group was so special?

26:46Because when I look at it, it is in hindsight. I mean, I saw Bjorn was reporting to you. And of course, there's Dennis Ritchie nearby and Ken Thompson. You also mentioned other people like McElroy and Hamming. So how did you know, though, at that time that it was such a special group? I think a lot of it was not so much knowing that the work they were doing was going to prove to be in the future important, but that they were just really clearly smart and seemed to be doing things that were interesting and relevant. Most of us used the work that our peers did. Certainly all of the things related to Unix, we just used that. That was our computing environment. The languages that were developed, the tools that were developed, and so on, we used them.

27:33And so you could get a sense of who's doing stuff that actually matters to me. And so I think that was part of it. Extrapolating long-term, you know, effect. We're not very good at that. Or I certainly wasn't figuring out who were the ones that were going to win Turing awards. No, not really. You worked with so many legendary people. Was there anyone that, I guess, or any story of someone who kind of impressed you the most or you thought, wow, their technical chops are just untouchable? There are several like that. Ken Thompson's the obvious one, I think. Certainly the best programmer I've everK, 18-bit words. So it's, you know, tiny little machine. And he's been fooling around with something to drive the disk on it.

28:41And he's thinking about, you know, how do you schedule disk operations so that it'll go fast and stuff like that um and his wife takes their young son off to california for three weeks and he thinks i could do something here and so in three weeks he builds himself an editor and assembler and an operating system and there you have it by himself yeah oh yeah absolutely when i used to write something you go to you know stack overflow or you kind of like look up how to write the code and then you write it how how does he do it without all that internet resource because he's a boatload smarter than you and i put together and this is before any of that stuff existed, right? This was 1969. And so he's probably writing the code on in assembly language,

29:32bear in mind, not, not any high level language. And he's doing it probably on some other machine just because it has some kind of text editor. And then he's making paper tapes that he carries to this tiny little machine and loads them and sees what happens. Oh my God. Yeah. So it's going back into the mists of time, but three weeks and he's got a working operating system. So I think that is a good example of somebody who's just off-scale good at what they do. And there were a lot of people like that at the labs. Yeah. I mentioned Doug McElroy a number of times. He was my first internship. He was notionally my boss and he was interested in storage allocators, ML, that kind of thing. And so he set me to working on something and I almost instantaneously went somewhere else

30:20and he didn't care. So I spent the summer doing something unrelated to that. And it seemed like it was fine because I got a come back next summer kind of offer, but he was the kind of guy who was exceptionally good at pretty much anything he wanted to do. I mean, Ken Thompson says Doug's the smartest person he ever met. So this is where We're multiple levels above me at this point. But Doug was extremely good at assessing, experimenting with, criticizing other people's work in a very constructive way. So he was a secondary or the outside reader on my PhD thesis, and he greatly improved my writing and the content of the thesis. And he continued to do that essentially for his whole life. He's still doing it.

31:09And he contributed a bunch of useful software, his own Unix sort program, Doug, Unix diff program compares two files, Doug, bunch of things of that sort. Um, he did language design and language design and development of his own. He wrote one of the very first PL1 compilers. He invented the idea of macros and it's just on and on and on and on. And he was also the department head who sort of had Ken Thompson in his department, though Doug wouldn't tell Ken what to do, obviously, but appreciated the work and was an incredibly effective technical critic of that kind of work. So, you know, gee, wouldn't it be nice if, or you said about that way, or just this sucks, whatever, to make stuff good. And that's a role that he played for the entire time

32:03that he was at Bell Labs. I first met him in 67, I guess, and he was, until he retired probably, he went to Carolli to mid-90s, something like that. This reminds me, when you mentioned department head, somewhere in my research, it might have been Hamming. There was someone that you worked with who was a head of the department with no reports. Matt Hamming. Yeah. Yeah, I never understood that. When I first met Dick Hamming, you know, he was a department head. You could tell because he had carpet on his floor. I guess he showed up in the phone book that way, too. But I couldn't figure out, you know, because I had this naive view that there was status associated with being a department head. And it was totally wrong.

32:48But he had worked very hard to get himself a department head so that he had whatever status or clout or whatever went with it for useful purposes, but no people reporting to him. And so I think that worked out very well. Because, you know, in any organization, if you're not at the right level, you may get ignored. And so I think that worked out very well. Because, you know, in any organization, if you're not at the right level, you may get ignored. And so it was harder, presumably, for something, for people to ignore our department head than an ordinary MTS. So he got the clout without any of the work of... The dog work. Yeah, right. Administering. the dog work and yeah right administering i mean he he put in his dues because he he came to the

33:25labs i think in 46 and did a lot of early stuff with computing is one of the very first people to realize that computer actual use of computers was going to be a very important part of all kinds of research in the future and he made this prediction that that at some point more than half of the research work would be done by computing, not in physical labs. And of course, they laughed at him. In my research, somewhere on YouTube, there's this video posted by AT&T, the corporation itself. And it's this, I guess, a film titled Unix making computers easier to use. Oh, yeah. Yeah. The AT&T did a lot of those PR films. Yeah. And there's a and you're you're in the video. You're one of the first people speaking

34:16and you have your legs up on some desk and you're kind of explaining as well. What is that? It's like any PR film. It's trying to convince people who don't know anything about you that you're a great whatever institution that you're contributing to the public good or whatever and so they hired a professional filmmaker kind of thing eric beloved i think his name was a long time ago and he came around and and he would do sort of what we're doing you'd have a conversation about something and try and get whoever he was talking to, to elaborate on what they were doing. And then he would splice it together into something that would feel good for AT&T. And at the time this was done, which I would guess is late 70ies, early eighties, something like that.

35:07Unix was kind of just starting to appear on the outside. It was a sort of a visible, interesting thing. And so part of the thing is AT&T is using computers to improve people's lives or our business operations or whatever. What is Unix? And so my job in this film, at least, and probably several others, was to sort of try to explain to a very non-technical audience, what is this thing, and what's it good for, and why is it new and interesting, or something like that. I skimmed through the comments on this video. It has a lot of views, actually. And the comments in there, one of the ones that has some of the most upvotes is it's saying that everyone in the film is you know not to be derogatory but kind of like computer nerd you know well we were we still are but but they highlight

35:58you as being a very clear communicator and a bit exceptional in your ability to convey the technical stuff you're talking about. And so I was curious, like if you have any advice on how to communicate technical work, but in such a clear way. Part of it is probably just putting yourself to some extent into the other person's shoes. They don't know anything about what you're talking about. So how can you explain it? It's the right combination of metaphors and examples and everything else that gets it across to them. And part of that, of course, it's nice to have feedback. So it's easier to do that if you're in a teaching kind of setting where you can see whether they're getting you or not. And if they're not, you can adapt.

36:43It's harder than you're doing a film because the audience is later, if at all. But there were a fair number of those things. We used to have Dog and Pony show as an image that's probably obsolete at this point. But AT&T or Bell Labs would bring through distinguished people on a tour of Bell Labs, and they would get demos of various things, you know, the usual stuff, demos of what interesting work is going on at Bell Labs, and they would go through a variety of rotation for Unix demos where we would get some exalted being accompanied by some appropriate level of Bell Labs management and others to sit on a couch in a little room and I would show them the wonders of Unix in some way or other. Well what are the wonders of Unix? I don't

37:42know. One of them was that it's easy to create programs by combining programs, the idea of pipes, or I can take the output of this program into the input of this program and maybe string several together. And I had a standard demo of that, which was looking for spelling mistakes in a document. Because what you could do is, here's a document. So what we could do is, here's a document, so let me collect the words in the document, get them into the lowercase, whatever, sort them neatly, and then compare them to another document, which is a dictionary. And if you find a word that's in your document, but it's not in the dictionary, it might be a spelling mistake. And it's one long pipeline, six or seven programs.

38:27So I could do this and people would sort of understand it. This is before WordPress and software really came along. So I do this demo and people would be impressed. The high point of this, one day, one of those visitors was a guy named William Colby. William Colby was the director of the CIA. And he was accompanied by a guy who literally had a briefcase chained to his arm. And Colby was accompanied by Bill Baker, who at that time, I think was probably president of Bell Labs, but he was also the head of the Foreign Intelligence Advisory Board. So he was a serious spook in his own right. And so they sat there. Now I had done this spell demo so many times before that I knew it took too long because old machines slow, etc.

39:12So what I did is the night before I ran it into a file. And then what I showed Colby was a shell script that said sleep two and then cat the previous sleep. And so Colby was very impressed with this, I guess. It does tell you you don't believe what you see in demos. What's in that briefcase? Is it a bomb or a gun? It's got to be nuclear codes, right? I mean, I have no idea. Interesting. The gentleman with the briefcase was not identified. One of the most famous books that you co-authored was the one on the C programming language. And since C kind of came from Bell Labs and you were so close to it, why was C so influential in your opinion like now looking back i think it hit a sweet spot in some sense of

40:07like efficiency and expressiveness um if you go back to when c was first created let's just call it 1972 ish or something like that machines were pretty wimpy they didn't have much memory the first machine that c ran on had i think 24k bytes. That was the whole thing. So you had to write a compiler, you had an operating system, you needed a bit space for files, what do you do? The disk, I think, was half a megabyte. So it's a little tricky. And so C was simple enough that you could see the translation into the underlying actual instructions of the particular machine, the PDB11 at that point. The language was simple. You could see the compilation. You could imagine building a compiler for it forwardly enough.

41:01It wasn't a big language. At the same time, it really was expressive. I mean, you could say what you needed to say very, wasn't a big language. At the same time, it really was expressive. I mean, you could say what you needed to say very, very effectively in the language. And I think it's hard to find a spot like that. And so one of the reasons I think C has succeeded as long as it has is that it still has that efficiency and expressiveness. I think the right word. Certainly, there are lots of other languages, which for various purposes are better choice at this point. Well, because there are plenty of things that C doesn't do, couldn't do at the time because you didn't have enough resources, right?

41:41You couldn't do a lot with fancy runtime stuff. You didn't want to do checking because checking would take code and you, come on, you've only got suddenly 4k bytes for your program. Now what? So an awful lot of things were cut that way. The other thing is the original target for C was to build the operating system. And so there's a set of things that you just don't need if you're building an operating system. So I think it was, for its time, a really, really, really good match. And then, of course, Unix and C was this sort of symbiosis. They went together. And so Unix was just so much better than any of the commercial operating systems at the time. Just so much easier to use, so much more productive and so much more fun

42:27that people used it in preference and then they would write programs in C and they would result in interesting tools. And so all of this was kind of a virtuous cycle. OpenAI, Anthropic and Cursor all use this product to make their lives easier. WorkOS is an API platform that adds enterprise features like SSO, SCIM, and RBAC to your app. These are things that you need to sell to other companies but aren't the main focus of what you're building. And now they've added more support for AI agents. For instance, Auth for Agents gives each agent its own identity with short-lived scoped tokens instead of a long-lived API key. So if something goes wrong you can revoke one session and everything under it dies.

43:07Another feature they have is Airlock, which is an authorization layer. Every action an agent takes is checked against rules that you can write in plain English. So it's not rubber stamping everything and it's not running unsupervised either. And lastly, they have Pipes, which connects your agents to over 300 third-party tools without you ever needing to manage a token. So if you're building SaaS or AI agents and selling to enterprises, WorkOS fills all these gaps in a few lines of code. Check them out at workos.com to learn more and get started. And I appreciate them for sponsoring my show. Yeah, when I learned, I guess, how to use Unix in college, there's all these these utilities like you mentioned diff

43:48that McElroy and then there's a variety of other ones grep and of course there's awk I remember I I learned that a long time ago good yeah um yeah what's the story behind that and why did you build it? So this is back in the mid-70-ish time, 76, 77, I guess. Al Aho and I had been friends for a long time. He went here to Princeton. He and I were undergrads at Toronto, although he was always a year ahead of me. And he was very interested in regular expressions, seeing patterns of text that you could use to recognize interesting stuff. I had been fooling around pretty unsuccessfully with the idea of some kind of text editor that would let me manipulate numbers as well as text, something like that.

44:41And Peter Weinberger, who I don't remember exactly how we met him, was interested in database kinds of things. And so we sort of talked back and forth and came up with this language, which combined some of those interests. The regular expression stuff from Al, the database-y flavor and report generation, RPG from Peter and the sort of, wouldn't it be nice if strings and numbers were kind of treated, were both first-class citizens of whatever we were doing. So we thought about it for a while. And then if memory serves, we came up with a sort of language design and then Peter went off one weekend and build it, not it. Peter's extremely good programmer too. Um, but he had the advantage of tools at that point because he could define the

45:36grammar with the acts that compiler compiler that Steve Johnson had built. And the lexical part with Lex, lexical analyzer generator that Mike Lesk had built. And so from that, building a language was not as much work as it would have been otherwise. There was some, just more of it was kind of built for you. And Al had the regular expression code already because that came from eGraph. And you take this on one very, very good programmer over a long weekend or so and you've got a language. And then from there, we just sort of evolved it slowly. And then Al and Peter dropped away from actual active maintenance probably five, 10 years later and I sort of inherited it. A lot of these Unix tools that everyone takes for granted,

46:24is that usually the story behind them? Which is you guys lot of these Unix tools that everyone takes for granted, is that usually the story behind them? Which is you guys are all using Unix and then you just realize, oh, I want to be able to pipe this to something that diffs or I want to be able to find something and then you guys just build it. Is that usually how these come about? I think a lot of them come from that. It's not from hypothesizing what somebody else might find useful. It's more like, what do I need? What's kind of bothering me at this point that I could improve if I just had a better tool or language or something? And I think that's true on almost all of the little tools that you mentioned.

47:03It's, you know, gee, I don't want to do this by hand or existing programs aren't quite right. Let me build something new and be very easy. For example, Make, which Stu Feldman did. You know, somebody told me, oh, my program didn't work. I can't figure out why it didn't work. Oh, it's because I forgot to recompile one of the files. And so could you in some way automate that? And that's another one of these weekend projects that Stu did. And then within a few days, he's got a bunch of users and then all of the mistakes he made in his first design, he can't fix. So I think all of the mistakes he made in his first design he can't fix. So I think all of these have that same purpose. Certainly there are things in awkward in hindsight.

47:50Oh my God, we should have done that better. A lot of the namesakes for these, they either explain themselves like diff. I think it's pretty clear. And then awk is the initials of the authors, but grep is a really famous tool. But what's the story behind the namesake of that? Oh, yeah, grep. Ken Thompson tells it very well. But the gist of it is that in the text editor, the ED text editor, which was the first real editor on the Unix system, there is a command called g, which says, do this command on all of the lines that match a particular regular expression. And the syntax is, in fact, g slash re, whatever the regular expression is, slash p. Print all the lines that match this pattern. And hence, grep.

48:41We talked a lot about Bell Labs. And you mentioned kind of the golden years. When you look back on Bell Labs and your time there, what is it that you miss most? Well, I miss the people, although I'm still in contact with a fair number of them one way or another. But the people were, it was just an amazing collection of really good, nice people, bright, fun to work with, lots of good ideas and so on. So you miss that. One thing that probably is not reproducible in a direct sense is the environment where there are just all kinds of new things to do. So it was an era of low hanging fruit, if you like. I suspect there's similar low hanging fruit, but I'm not in the right orchard at this point. I just don't know enough.

49:25But maybe some of the AI stuff that's going on is the moral equivalent at this point. So I think those are the things that are perhaps the most things that I miss. Bell Labs gradually became more of a conventional company as AT&T went through troubled times and split itself and split itself. So all the fission products were smaller and it meant that the Bell Labs, the big cohesive bunch of people working on all kinds of things became smaller, more fragmented and didn't have as much money. And therefore we're forced to do the kinds of things you don't want to do, like raise money. So that part I don't miss at all. In one of the classes that you taught, there's a video somewhere buried deep in YouTube where you are trimming your beard in the lecture. Do you remember that? And what's the reason for,

50:18you know, grooming during the lecture? I remember that one. That is actually, you should ask David. He was in that class. That was at Harvard. That was the first lecture of CS50, the year I taught it at the beginning. So that'd be September of 1996, I think. I had never taught a big class before. The class had been taught by Margot Seltzer, who at the time was in computer science there. And she was taking a sabbatical and she asked, I would be interested in teaching her a course. And I thought, only chance I'll ever get to teach at Harvard. Why not? But Margo had a shtick that she did at the beginning of her first lecture, which was trying to explain to people why it's hard to tell a computer what to do.

51:03And so she would get the audience in her class to direct her in making a peanut butter and jelly sandwich. And, you know, it'd be very easy to get the jelly on the desk and the peanut butter on your head and, you know, stuff if the instructions weren't clear. But I'm not a peanut butter and jelly kind of person. And I thought, what's the equivalent? And then it occurred to me, I have this ratty beard. So I brought in a collection of equipment suitable for trimming a beard, ranging from a pair of scissors to electric hedge trimmers. And I got the audience to try and guide me through trimming my beard with this stuff. And I don't remember, I think actually the headstrimmers were plugged in, but they would want to be very careful.

51:48So you mentioned that was your first big class? Yes, 457. Was public speaking nerve wracking at that time for such a large group? No, I think originally when I was like a grad student or something, public speaking was very challenging. But one of the things I did first at Bell Labs in one of those, I think, maybe even intern years, I don't remember now, was Vic Fasatsky, who was across the hall from me, said, we've got a bunch of physics guys who need to learn Fortran. Would you mind teaching them? And so I did that. And so the teaching experience got me over this fear of public speaking totally, completely. And so I had done a bit of adjunct teaching while I was at Bell Labs earlier before the Harvard gig, that was by far the biggest, at least more than the order of magnitude, the biggest.

52:48But at that point, it's not the size of the audience so much. It becomes, it's a theater performance. And David Mayden can tell you that more accurately because he's really good at it. So if someone who is a student who's scared of public speaking asks you for advice, what would you tell them? I think doing it, getting into an environment where you have to talk to people and in at least small group to begin with, and then maybe bigger one is OK. And I think there's no better way than actually just doing it, getting out there and forcing me. So, so I'm past the stage where I worry about that sort of thing. I guess conference presentations are sort of like that too, but, but teaching's better

53:35because it's a more intimate setting for the most passing over 400 people. It's a more intimate setting. And so, um, you've got a better way to judge whether you're getting in contact with your audience, whether they're understanding you or not. And if you think of them as friends or something like that, and then you blur a little your vision so you're not really looking directly. It looks like you're looking at them, but you're not. Or you focus on one person in the audience who seems to be resonating. All of these things, I think, help. But after a while, it just becomes practice, and then you don't worry about it. I know you still lecture here at Princeton from time to time, and it seems like more recently the education may be changing because of some of this LLM AI stuff.

54:23I mean, unprecedented access to answers, I guess. Do you believe that LLMs are a net negative or a net positive when you look at education? I think it's too early to tell. I can see plenty of elements of both sides of that. One concrete example that I have heard reported by all kinds of people around here is that students don't come to office hours. They're presumably getting whatever it is from their favorite large language model. And so they don't come in and talk to faculty or the preceptor grad students or whatever it is. They just don't do that very much. And I think that one's a net loss. The bandwidth when you're talking to somebody in person is enormously higher than when you're talking to Claude or whatever.

55:18And the other thing is that the human contact that you get from this is useful in all kinds of ways, not the least of which is that if you come in and talk to some faculty member, that person now know who you are and they can say, oh, did you know? Here's an opportunity. Here's somebody looking for a job, whatever. So they're missing the kind of... It's not transactional that they're missing that human connection that helps in the future. So I'm sorry to see that the office hours go away. I think a weird, I don't know why I called it an upside or a downside of this in computer science in particular, enrollments are down. So we have many fewer computer science majors than we did a few years ago.

56:07And that means classes are smaller. Not entirely because many of those people just went to other departments, but they're still taking our courses. But they're somewhat smaller. And that means that there's more contact with the students. And I think that's good. What percent down would you say? Our numbers are, I don't know where they're, I think they're more extreme for some unknown reason, but I think our, the class that just graduated in the summer, spring of 2026 was a little over 200 computer science majors. The class that will graduate two years later is probably going to be less than half that. Less than half. Yeah. Wow. Maybe even down to a third. We don't know because there's a staggered way in which majors appear,

56:57but, but I would guess that if it was 200, it'll be sort of 80-ish, 90-ish, pure desk work, but quite a bit lower. Those people have gone in here to electrical and computer engineering and mechanical and aerospace engineering, because those, I think, are more concrete, hardware oriented, less likely to be replaced by large language models. So the kids are voting with their feet. I think to some extent that's totally understandable. I think they may be overreacting, but I don't know. And if you just read the popular press, my God, we don't need programmers anymore. I think that's fortunately oversimplified, but, but I don't, it's not my problem in the sense that I have a job and they quite rightly are worried about what they're going to do when they get out of here.

57:50So the total number of students that go to Princeton is roughly constant. Oh, it's constant. It's totally constant. Okay. But the proportion that goes to computer science. In different fields is different. And I don't know, I know those particular numbers for where does it look like computer science people went over the last, you know, voting with their feet right now. And it looks like mostly to electrical, computer engineering, mechanical aerospace for the robotics aspect. I saw your, an extra on the film, A Beautiful Mind. It's a great movie. And before the interview, I was trying, I was like kind of combing through the movie trying to find you. You know, how did that come about? And what's it like to be a part of such a big movie?

58:38You know, that was enormous fun. They did a casting call for that because parts, big parts of it were going to be shot at Princeton. And this was just shortly after my wife and I had moved to Princeton. So I don't remember the date, but call it 2001-ish. So they had a casting call. And so a bunch of people showed up in one of the big classrooms and they heard the story of what was going to happen. And then some guy wandered around and said, you. And he didn't pick my wife, which I thought was nuts, but he pointed at me. OK, so this was the casting call. And then later on, I got an invitation. Please come and we're going to do some shooting of the Nobel Prize ceremony. So you'll find me there. I can tell you where to find me. The reason you don't recognize me is

59:31first, nobody is wearing glasses because they would reflect. And secondly, I'm wearing black tie, something which I had never worn in my life. This is a Nobel Prize ceremony. And it was shot in the Newark Performing Arts Center. So a place I had never been before. And it took about 22 hours to do that. But because you got there at sort of five in the morning, you had to be dressed properly. And then there were shooting and shooting and shooting and shooting and lots of dead spots while they rearranged the cameras and so on um but it was really interesting and i got paid not equity rates but i got paid i got something i would have been better off to flip burgers at mcdonald's for the day and then the movie came out and and it was fine but the

1:00:21wonderful thing is that i got an air dish bacons bacon number of five erdős bacon so okay what those numbers represent how far you are from those people in your sighted works in in their related works so my my erdős number is three because i can go through several people a couple of paths to erdős in steps three steps but my bacon number is two because i was in this film with somebody who was in a film which was kevin bacon so anyway that's the the gist of it i actually met john nash a number of times after that um the not the actor the real the real john nash yeah yeah he was you know he was kind of let's call it introverted or something like that, but perfectly fine. The scary story for me, I was giving a talk.

1:01:10I don't remember how it came about, but I was giving a talk to an internal group in the math department about something that I had worked on. I'd forgotten what it was. And I was, you know, into this. I had been going 10 minutes or something. And I was on a roll. And I'm not scared of audiences or anything. I had a good time. And John Nash walked in. But I could just feel everything tightening up inside. And then he asked some question. I don't remember what the question was or anything like that. But I got over it. But that's one of the few times where public speaking is a bit of a threat. Another interesting factoid that I wasn't sure if this is true, but so in the Git repo for the Go programming language,

1:01:59actually the first commit in it is from you in 1972 supposedly but the you know the programming language started in 2008 so yeah right i have no idea what this is okay you never saw this is news to me okay yeah it's supposedly i mean i found it says first commit to the go get retold oh is it a whole world example? That's the B program. Yeah, yeah, yeah. It's in B for some reason. So. And this is followed up by commit 1974 to convert it to C. And then another one to convert to NC. So maybe Robert copied your Hello World repo and used it to start Go. I never used Git at that point. I don't think I started using Git until maybe 10 years ago. Interesting. So then, was there the notion of version control back then?

1:02:56Because somehow... Version control came along in the mid-70s. There was something done by the programmers working at people, I think, called SCCS, the source code control system. And that was widely used inside the labs and I think outside. And then there was RCS by Robert Tichy, which was a variant of the same thing, revision control system. And then there was CVS, was it? Concurred version system or something like system. And then there was CVS was it? Concurred version system or something like that. And then some other version of it and then Git and others scattered around. So it's an old idea, but in 1972, it did not exist. I mean, Unix didn't exist in 1972. That B program ran on something else.

1:03:43Interesting. Okay. Yeah. I guess it'll just remain a mystery. Maybe Robert can answer if I ever interview him. In your memoir, there's a thank you to Grace Emlin. And then I dug a little more and I also found this Bell Labs alumni tracker and it kind of shows where all the alumni go. And Grace Emlin, it said, relocated witness protection program. And so curious what that is about. There was this period of time, forgotten the dates, when Bell Labs decided that employees had to wear their badges so that if you were walking through the hall, people would know that you were an employee as opposed to a tourist of some sort or other. And people were not very enthused about wearing badges. And so there was a bunch of kind of quiet insurrection about it.

1:04:45And one of the bits of insurrection was the creation of badges that were fakes. And so Grace Emlin was a creation of, I think it was probably Fred Gramp who did it. There's this Gremlin thing. And so G-R-M-L-E-N, Grace. And we managed to get Grace into a variety of official records for the company for a while. And she, this little Gremlin-like thing, this high set in the Unix room with her badge on. But there were other people who had weird badges. I had a badge with Mickey Mouse on it. And so I probably still have it in my desk, but I will try to get it. That I used to wear all the time. I mean, it was, I wondered, nobody looked at the badges. They just see a blur and there was a badge. So it was okay.

1:05:39So I wore this badge all the time. I wore it when I met Bill Gates at one point. I don't think he noticed either. So people didn't take kindly to bureaucratic stuff, even though probably badges were a fine idea. Was the badging system digital at that point? No, it was just paper, pieces of paper. They were pieces of plastic, but you could put your own paper in front of it. Another thing, so I found somewhere on the internet in some very old repository, there was a secrets file that was committed to the repo. And everything in there is encrypted, but it was encrypted by the old DES security standards. So it's possible to brute force unencrypted with modern day. And so you and all your colleagues'

1:06:35passwords are actually... So I saw yours is... I mean, I'm assuming it's okay. Yeah. It's just slash period, comma, slash period, comma'm assuming it's okay. Yeah. It's just slash period comma slash period comma. Really easy to type quickly. Yeah. No, it's funny. I hadn't seen that. I got mail from Eric Schmidt saying, gee, did you see this? Sent to several of us. And so it was intriguing to see what the passwords were. I guess you're probably right. It probably was either DES or some World War II machine, like a Hagelin machine or whatever that the CRIP program was based on. In our defense, this was at a time when the machines weren't networked. And the passwords were kind of, why would you need them anyway, sort of thing.

1:07:17And so, you know, we didn't pay much attention to them. And I guess the other thing is the password file. This was, I think a tape that had was from Berkeley. And so I don't know, somebody must've copied the password file from the research Unix things at Bell Labs over to some Berkeley system. Don't know how it got there. Coming to the end. Yeah. I know you, you wrote a ton of books in your career, very prolific. I mean, there's the C book that was just one of many, though. What's your motivation for writing all these books? I find it fun. I think it goes back to something you asked about earlier, trying to explain stuff to people who are not experts in it. In some way, I find that attempt to communicate

1:08:05rewarding, worthwhile. It's a way to have influence at a distance, perhaps. So teaching is kind of retail. You're in the same room with a bunch of people. Writing a book is wholesale, if you like. You won't meet most of the people who might look at a book, but with luck, they will also learn something from it. Partly, it's a way to learn the stuff yourself. And I guess partly it's just that once you've done one, you do more. I remember a conversation with Don Knuth eons ago where he said that there are people who have written no books, there are people who have written one book, and there are people who have written many books. And so I guess I'm in that third category, sort of. Yeah, for me, it's kind of fun. And so I'm

1:08:54still doing it. This is your chance to do a commercial announcement. Yeah, what's your latest book? Yeah. So I did a book over the last year or so, a history book called important ideas in computing will appear from MIT press in January end of commercial announcement. Is that the memoir? Oh no, this hasn't come out yet. Yeah. This hasn't come out yet over there underneath your camera is a, a, the cover of it, uh, of shifts. Yeah. Right. Okay. It's, it's available on Amazon, but it won't appear until January or something like that. But the idea is that there's a bunch of interesting things that have happened in computing where something, there was a change. In a different context, you'd call it a paradigm shift to Thomas Kiernan idea, but it's not

1:09:39really quite. But the shift from analog to digital being different. I mean, all the camera stuff you're doing here would not be feasible with film. Right. And so there's this stored program computer, the idea that you can build one general device that will kind of do anything you want just by giving it different instructions. And so that's a big deal. There's all the integrated circuitry stuff that the evolution started with the transistor and went to ICs today. All of that stuff. Again, all of what you're doing here wouldn't be possible while our computers wouldn't be. Programming languages. You know, if we were still writing assembly language, it would be pretty bad. But the evolution of programming language is making it ever easier to

1:10:25tell computers what we want to do and so go on like that pick another and then the the final thing that's a big big paradigm shift that's different i think from most of the others is that we're in the middle of it and it's incredibly visible and that's the ai large language model stuff which is changing incredibly rapidly and is affecting everybody and that's the AI large language model stuff, which is changing incredibly rapidly and is affecting everybody. And everybody's noticing it, which is different from most of the other things that we've talked about. So, um, so my wife, who is not a computer person is interested in learning more about what's going on with artificial intelligence, large language models, explain this, what's

1:11:04that mean? What is the future going to be? And so that paradigm shift, I think, is really, really, really uncertain. And we are very much in the middle of it and everybody knows about it. So anyway, now I've given you the synopsis of the book. Go buy it. Yeah. You know, with this AI and all these LMs, one of the big things that we've seen is that they can write all the code, actually. Like a lot of my peers genuinely can computing or love writing code, it's actually kind of sad for them to see, you know, these things become obsolete, like typing things out and stuff. And I was curious in your career in computing, there must have been points where something became obsolete, maybe like the punch cards or I don't know, something like that.

1:12:05And I guess, how did you feel at that time? Yeah, well, I don't miss punch cards in the slightest. No way. I was thinking, you know, my thesis was done on, my PhD thesis was done on punch cards and that was three boxes of cards. And I realized that that was 30 pounds of stuff I had to carry around for my thesis. So that's, so there's certain things like that I don't miss. There are other things that you miss the kind of, call it the intellectual challenge or the puzzle solving or the whatever, where you write a piece of code. So right at the moment I'm teaching class that involves C programming. So it's back to early days and, you know, I haven't written much C for a longish time and it's kind of fun to get back into it

1:12:49and sort of rethink and relearn, you know, that's what pointers are all about kind of thing. So I suspect most people don't miss that sort of thing because the memory management aspects are a pain. On the other hand, the challenge and the fun of figuring it out and getting it to work and so on is there. Now, the same fun and challenge and getting it to work is going to be true if you're writing in Python. Is it there if you prompt your favorite plot or whatever to generate it for you? I don't think so. I don't think that at all. And even once the program is generated for you, you still have to see whether it works and whether it's the most effective way to do what you want. And is it really doing what you want

1:13:35or should you have wanted something different? And all of those sorts of things. And that's in an environment where you know what you're doing. I've been using mostly Claude, but others as well, to generate SQL because I'm not an SQL expert. And I have a colleague over at the Institute for Advanced Studies who has a database. She's not a programmer at all, but she wants to query her database effectively. So I need something to generate SQL from natural language queries. So I want to say, give me all of the whatevers that have this property and get the large language model to generate the SQL and then run it through the database. How do I know whether it gave me the right query? Because I'm not an SQL expert, and if we already knew the answer,

1:14:24we wouldn't need it. And so I'm wrestling with SQL expert. And if we already knew the answer, we wouldn't need it. And so I'm wrestling with that. And my observation is 90% of the time it generates a perfectly fine query and 10% of the time it doesn't. It gives you a totally wrong answer. And I don't know which is which. It sounds like what you're saying is you need some domain expertise. Otherwise, you can't be the judge of it. You need domain expertise. Probably it's the same domain expertise you always needed. You need ways of validating what you do because you can't be sufficiently expert that you can test a big program all by yourself. So you need something, again, to help you with generating the test.

1:15:02But then you need something to evaluate whether the tests were properly generated. And then there's this infinite regress of, you know, check the checker who checked the checker kind of thing. Um, now I'm oversimplifying and I'm not a high powered user. And I know plenty of people who, as you described her of, you know, essentially everything they used to do, they have outsourced to something like a large language model. And I don't know what they're giving up by doing that. In one sense, they're getting a lot out of it. They're probably 10 times as productive as they used to be in terms of code to get some functionality. And at the same time, they're probably losing 10% of their brain cells or failing to exercise them properly.

1:15:48And I just don't know. It's early. And things, whatever we say today in a week or a month will not probably be correct anymore. The place where this shows up, right around here at least, is kids worrying about what's going to happen when I get out of here. I wanted to be a software engineer. Does that job still exist? And the answer is maybe, but it's different than it would have been two or three years ago. And by the time they graduate in a year, it'd probably be different yet again. And the question is, how do we, on the faculty side of things, let's say, help them manage this? What do we try to teach them? How do we get them to have the right habits of thought or whatever so that they are able to go thrive in this brave new world?

1:16:40And the short answer is, I have no idea either. And I don't think anywhere does. In the world you describe, which is today's world, the models are not perfect. There's a lot of subtleties where they get things wrong. But in a world where they are perfect and they're kind of doing everything, what, just like out of curiosity, what happens to a computer science major? Well, I mean, first you have a premise there, which is that these things will become perfect. And I suspect they won't become perfect, although they may become a lot better than they are right now. So there's probably still going to be need for somebody to assess their perfection. I think the nature of what people do with them will change in the same way. We don't have people writing assembly language very much anymore.

1:17:27We trust our compilers. And in fact, we don't write C very much. We write higher level languages. And so this may be another step up the, call it the abstraction chain or something like that. But you're still going to need people to guide it. And what's the right sensible direction to go? The other thing is that people will be able to build more interesting things because of this. So I have a student from a couple of years ago, graduated a couple of years ago, who is doing a very, very successful, interesting company using artificial intelligence, large language models to do translation of natural languages, mostly for user interface kinds of things. And I think his company is going to be very successful and it's interesting work.

1:18:13And as the large language models improve, it just means that he can do a better job at what he is already doing and offering to his customers. So I think that kind of thing will probably continue to happen. When C came out, were people mourning assembly language? I think it would be before that. I think it was when Fortran came along. If you look at what John Backus said when he was in his group at IBM working on Fortran, this would be roughly 56, 57, that kind of era, I guess. He was very afraid that people would not accept this new tool because it would not generate code that was as good as people could generate that the assembly language came out or the program wouldn't be as efficient. And so in the design of Fortran, he quite consciously stayed away from

1:19:11elegance and so on and aimed towards efficiency of the translation. And so it was a genuine concern. And at some point along the way, their program, their compiler started finding optimizations that people didn't. And that's the point where he figured maybe this is going to fly. Now, after that, I suspect people did mourn, you know, the skill and the whatever that goes into assembly language program. But for most people, nah, they just wanted to get the results. And Fortran was a boatload better than assembly language in multiple directions. It's easier to learn. If you were a physicist or a chemist, you could learn Fortran where you never learned, you know, I have a 7090 assembly language. And furthermore, if you got it

1:19:55working once, you could put it in multiple different machines. When you look across your whole career, because you've worked in a bunch of different programming languages and you've taught a bunch of different ones. Are there any that stick out to you as your favorite or your least favorite? If I think about what I do on a day-to-day basis, if I write a program, it tends to be a small one and it's an awk. It's kind of silly, but okay. At least I know it. Um, if I were to write bigger ones, I would almost surely write them in Python because for many things, that's the right compromise or it's certainly efficient enough for anything I do. Um, and it's totally expressive for the kinds of things I might want to do.

1:20:40I will occasionally go back to C because I've got some older program and maybe I want to do something with it, or as I've said, I'm teaching it at this point. So those are kind of the languages that I wind up using. Not very many other languages I wouldn't use. So who shall I insult today? I used to in my class, I haven't done this for a long time, but I used to basically write the same program in as many languages as I could find. Um, it was a simple program. You would take text input lines of arbitrary links and put them out so that the lines were all at most 60 characters or something. So it was a simple minded version of the reflow that you would see in a, in a browser. And I would write

1:21:24it in every language I could lay my hands on. I had two dozen or more of them and I show them in class. And the question is which ones ran faster and which ones were in some sense, small or easy to understand or whatever. And lock was pretty fast and it was the smallest always. It was about 15 lines of code to do this job. And C was always the fastest, but it was harder because you had to worry about memory management a bit, and it was clunky to do strings. And the other scripting languages like Perl and Python and PHP, and they were variously sort of okay, Perl was always the faster one. And some of the high powered languages that were supposed to be better were actually slower, Java was slower than the scripting languages.

1:22:06Kind of weird. C++ wasn't as fast as I thought it would be. And at the far end of it was Haskell. And it took me weeks to write the Haskell program, whereas Lua, a language I had never touched, took me about half an hour. Look at the manual. Oh, I see. Done. It took me about half an hour. I look at the manual. Oh, I see. Whereas Haskell took forever. And then I showed it to some Haskell expert. He said, oh, but you have to import this character library that does this and then it ran faster. What made Haskell take so long? It's a different way of thinking. And I just didn't crack it. I really didn't I really didn't and I think part of it was the problem is you're taking input in one form and

1:22:51not asynchronously but not at the same cycle you're trying to produce output so your lines are varying lengths and you want to produce lines with the same length and that mismatch of input and output kind of frequency didn't fit naturally with Haskell as I understood it. Now, this is not a knock on Haskell. I mean, there are people who love it, but I'm not one of them. I saw somewhere on the internet that somewhat recently in the last few years, you added Unicode to AUK or the repo of AUC that you're kind of contributing to. And it made me think, what motivates you to continue to write code? Well, it's fun. It's this intellectual challenge that we talked about. And I think part of it was that for AUC in particular, I wanted to actually be able to process Unicode because an awful lot of text in the world is in Unicode at this point, where by Unicode, I mean UTF-8. So I would,

1:23:50I wanted awk to work properly on that kind of stuff and it didn't. So that was part of the change. The other thing I did at the same time was to make it work with CSV files because I had data that was in CSV files and it was very clunky for processing that. And so added a mechanism so that you could say, Hey, do CSV properly. And the input mechanism, I think both of those were triggered probably by working on a second edition of the book. And that was done in, you know, just a couple of years ago and at this day and age it would be really embarrassing if you couldn't handle unicode for young people a lot of times they're they're trying to discover i guess their passion or the the thing they want to work on it sounds like

1:24:37you found it pretty quickly in programming and you're naturally enjoying just the act of it if you had a student that comes to you or a young person and they ask you, how do I find that thing I should be working on that I should be passionate about? What would you say? It's a good question. I think probably what you tell them is to go do as many different things as you can in the hope that something will resonate. I mean, how do you find the perfect partner for your life or whatever? You're not sitting in your room and think about it. You go to parties or whatever, or maybe use some app like Tinder or whatever. I don't know. But you do things that get you out in a place where you might discover the sort of thing that you're hoping to find. It's an

1:25:21imperfect process, obviously. But I think if you don't do things, if you don't try different things, then you may not stumble into it. A long time ago, I think it was Dick Hamming said to me that, you know, it was Nancy Reagan who said, just say no. This was the don't do drugs kind of thing. And Hamming said, just say yes. Not to drugs, presumably. But the idea that if somebody comes along with something and you think, I don't know, let me try it. And applied with some common sense, that seems like a reasonable way to handle a lot of different things. It's hard to know, and what works for one person isn't necessarily going to work at all for anybody else. And so, you know, giving people career advice or life advice,

1:26:11be careful if you get it from me. And then, yeah, last question for you is, you know, with all the experience that you have now and going through your career and everything we discussed, if you could go back in time and give yourself advice, knowing everything, you know, now, what would you say? I think if I look at it, a lot of what I have done, you've seen a Galton board. It's this thing where you drop a marble. There's, there's an array of nails and you drop a marble in at the top and it comes out somewhere at the bottom. And if you repeat it enough, you get a normal distribution of distribution of marbles across, depending on which way it would bounce. And so I'm like a ball dropped into a Galton board and, you know, and I come out somewhere

1:26:58at the bottom, but the decisions, which nail, when I hit a nail, which way do I go? I have no idea. And a lot of it is serendipity. However, one I think genuinely useful observation, a lot of this stuff comes from talking with Dick Hamming, but it was Pasteur who said chance favors the prepared mind. So the more things you have thought about, wondered about, done a bit with, met people on, whatever, the more likely it's some one of those will actually lead you in the right direction. On that board, you're saying a prepared mind kind of bias those outcomes a little. Towards a potentially better outcome. Yeah, I think so. Well, yeah, that's all my questions. Thank you so much for your time. Really appreciate it.

1:27:40My pleasure. If you liked it and you want to see the show grow, please support with a comment or a like. Also, if you have any recommendations for people you want me to bring on, please drop a comment. Guests like Barbara Liskov, Mike Stonebreaker, Mark Brooker. These were all people that I brought on because someone left a comment. On another note, aside from the podcast, I'm working on building the ergonomic keyboard that I wish existed. Here's a glance at the prototype. It's a split keyboard, so there's two sides. This is in the case. But yeah, we launched on Kickstarter and we hit our goal within eight hours of launching. I really appreciate it if you were one of the people who grabbed one of the early units. We're now working on the long journey of

1:28:24building the tooling now. And so if you still want to pick one up, I've left the late pledges open on Kickstarter. So you can grab one there. I'll put a link in the description. Thank you again for watching the podcast and I'll see you in the next episode.