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

Brian Kernighan is a former Bell Labs member of technical staff, co-author of the original C book, and the one who popularized “Hello World.” We talked about what Bell Labs was like and the stories behind all the famous tools that were built there. • My ergonomic keyboard project I mentioned, you can follow along here: https://read.compose.llc/ • The Kickstarter page for it: https://www.kickstarter.com/projects/ryanlpeterman/compose-simple-ergonomics-beautifully-done Podcast links: • YouTube: https://www.youtube.com/watch?v=sMllOlxVgD0 • Apple: https://podcasts.apple.com/us/podcast/the-peterman-pod/id1777363835 • Transcript: https://www.developing.dev/p/e072-brian-kernighan Thank you to this episode's sponsor for supporting my work: • WorkOS: makes your app Enterprise Ready with easy to use APIs to add SSO, SCIM, RBAC, and more in just a few lines of code, check them out at https://workos.com/ Timestamps: (00:00) Intro (00:42) What Bell Labs was and how he got hired (06:34) Why so many inventions came from Bell Labs (14:15) A day in the life at Bell Labs (27:55) The most impressive people he worked with (33:50) The AT&T film explaining Unix (39:46) Why C was so influential (43:25) How awk was created (48:40) What he misses most about Bell Labs (54:10) Are LLMs bad for computer science education (01:01:46) His 1972 commit in the Go repo (01:03:43) Grace Emlen, the fake Bell Labs employee (01:07:39) Why he writes so many books (01:19:58) His favorite and least favorite languages (01:24:28) Advice for students and young people (01:27:42) Outro Where to find Brian: • Personal website: https://www.cs.princeton.edu/~bwk/ • Princeton University faculty profile: https://www.cs.princeton.edu/people/profile/bwk • Wikipedia: https://en.wikipedia.org/wiki/Brian_Kernighan Where to find Ryan: • Newsletter: https://www.developing.dev/ • X/Twitter: https://x.com/ryanlpeterman • LinkedIn: https://www.linkedin.com/in/ryanlpeterman/ • Threads: https://www.threads.com/@ryanlpeterman • Instagram: https://www.instagram.com/ryanlpeterman • TikTok: https://www.tiktok.com/@ryanlpeterman Referenced in this episode: • UNIX: Making Computers Easier to Use: https://www.youtube.com/watch?v=XvDZLjaCJuw • Brian Kernighan’s first Harvard CS50 lecture (1996): https://www.youtube.com/watch?v=6Ba1XFVy7qw • A Beautiful Mind: https://www.universalpicturesathome.com/movies/a-beautiful-mind • Shifts: Important Ideas in Computing: https://www.amazon.com/Shifts-Nine-Ideas-Revolutionized-Computing/dp/0262064294/ • Labscam (Penn & Teller at Bell Labs, 1989): https://www.nokia.com/bell-labs/about/dennis-m-ritchie/labscam.html • Labscam video: https://www.youtube.com/watch?v=qnsmDNamd2g • Understanding the Digital World (new edition): https://www.amazon.com/Understanding-Digital-World-Computers-Internet/dp/0691288879

Speaker names marked ? are inferred from speaking time and the show’s known hosts — they are not voice-verified.

• 0:00Speaker 00

  And so in three weeks, he builds himself an editor, an assembler and an operating system. And there you have it.

• 0:05Ryan Peterman?

  By himself?

• 0:06Speaker 00

  Yeah, oh yeah, absolutely.

• 0:07Ryan Peterman?

  This is Brian Kernighan, 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.

• 0:18Speaker 00

  There were no deadlines. There were no projects. There were no objectives, goals, whatever set by other people.

• 0:25Ryan Peterman?

  There was a secrets file that was committed to the repo. And so you and all your colleagues passwords are actually.

• 0:32Speaker 00

  Yeah.

• 0:33Ryan Peterman?

  So I saw yours is, do you believe that L L M's are net negative or net positive?

• 0:41Speaker 00

  So who shall I insult today?

• 0:43Ryan Peterman?

  Here's the full episode.

• 0:49Ryan Peterman?

  Could you explain what Bell Labs was and what is the story behind you getting a job there?

• 0:55Speaker 00

  So Bell Labs was like the research arm of AT&T was founded in, I think, nineteen twenty-three, twenty-five, 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.

• 1:33Speaker 00

  In nineteen, is it in call it sixty-three, something like that, early sixties. They basically moved the whole operation to New Jersey, northern New Jersey, a place called Murray Hill, which near Summit and things like that. So call it twenty-five miles west of New York City. And that was a big operation. There were probably three thousand 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.

• 2:13Speaker 00

  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 nineteen sixty-six, I was a grad student here at Princeton. But I got an internship at MIT in Cambridge, working in Project MAC, which 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, just starting up.

• 2:55Speaker 00

  And that was a lot of fun. I enjoyed it. I'm not sure I ever did anything that was very useful, but, 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 of nineteen sixty-eight. And there I worked with Shannon Lin and he and I worked on a problem which had been suggested by my advisor here.

• 3:41Speaker 00

  And this is 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.

• 3:59Ryan Peterman?

  Escaped Princeton?

• 4:00Speaker 00

  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 two thousand in the group that had done or was doing a variety of things.

• 4:16Ryan Peterman?

  Did you consider other career opportunities at the time?

• 4:19Speaker 00

  You know, I think I didn't consider any other option whatsoever. I, I 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 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 was a lot of back and forth between the two institutions.

• 5:00Speaker 00

  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. And so that probably said, well, these folks from Princeton are maybe okay. So I'm grateful to him too.

• 5:20Ryan Peterman?

  Nowadays, Bell Labs is so legendary, but 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?

• 5:33Speaker 00

  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 example. And a lot of things related to communications, that's where information theory came from. It'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.

• 6:17Speaker 00

  And that was, you know, largely, I will say the physical sciences kind of thing, but it obviously sort of spread out into other things that were partially related. And certainly the mathematicians were absolutely first rate as well. Tended to be applied mathematicians rather than theoretical ones.

• 6:35Ryan Peterman?

  Everything you just said there is 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?

• 6:56Speaker 00

  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 eighty percent, but it was a very substantial fraction of the whole 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 used evaluated by lots and lots of agency, states and 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.

• 7:40Speaker 00

  And the quid pro 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 two percent of their pretty much guaranteed revenues to fund a research operation that would let them improve the service. And so that was the, the basic, call it financial arrangement. And the other thing is it was very stable. You could sort of predict it would be this steady increase in

• 8:16Speaker 00

  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 time.

• 8:53Ryan Peterman?

  What gave this lab such recruiting pull in your opinion? Like, how did, how are all the best people coming to this place?

• 9:02Speaker 00

  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, so that would be, let's say, anybody doing physics, chemistry, materials, all of that kind of stuff.

• 9:45Speaker 00

  I think somewhat the same would be true of anything related to mathematics, especially the mathematics of communication or anything related to communication systems. So that's where Shannon was. That's where Hamming was.

• 9:57Speaker 00

  Boda, Night Quest, all those people before those. So that kind, 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 earlyish, because remember I was, I went there in nineteen sixty-nine. So this was, computers were still pretty young at that point.

• 10:31Ryan Peterman?

  A lot of those names you mentioned, I mean, they were in my, you know, textbooks when I was studying. And so they're, 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?

• 10:51Speaker 00

  Well, it's, 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 nineteen sixty-seven, 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. This never happens. But it did happen. And so I'm sitting there on the very first day at about, you know, roughly. Eleven 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.

• 11:36Speaker 00

  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. And

• 12:02Speaker 00

  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 of those kinds of things.

• 12:27Ryan Peterman?

  When I interviewed Leslie Lampert, 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, not as respected as math and physics, or maybe because it just was a burgeoning.

• 12:46Speaker 00

  That's brand new. The same thing happened here, I think. I 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. Unbelievably naive. And I had thought to work with a guy named Arthur Samuels, who had done some interesting stuff in computer chess playing. It's a hurt. 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.

• 13:30Speaker 00

  And a cohort of young people who had interest in computing, they had just gotten their degrees from someplace and they were very young. Wanted to do computing.

• 13:42Speaker 00

  And I don't know whether any of them ever got tenure because the older folks didn't really grok the newer field. John Hopcraft, to pick a random example, was my technical advisor for a year. Although it was quickly discovered I was not a theoretician.

• 14:00Speaker 00

  But you know, John went on to win a Turing Award and was dean of engineering at Cornell. He's all kinds of great guy. But he wouldn't have gotten tenure here at that particular time because the, the computing science aspect of things was too new.

• 14:16Ryan Peterman?

  Bell Labs is kind of famous for very hands off management and letting the engineers kind of do what they were doing. What is a day in the life like of a engineer working at Bell Labs?

• 14:30Speaker 00

  Well, first thing I was, don't think any of us would have called ourselves engineers. We were not doing whatever you did, but, but I don't think that engineer was the right word because we weren't really engineering.

• 14:43Ryan Peterman?

  It was a member of technical staff.

• 14:45Speaker 00

  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 you had been working on some kind of program or maybe you were trying to prove a theorem. That's not me.

• 15:18Speaker 00

  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.

• 15:48Speaker 00

  So in a sense, maybe not too different from what you would find in a university, except there were no students. And so that meant you could do it full time. The, the trade off 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 there, I was supposedly the bright, new, young person. So mainly the lack of students, which I think is a mixed blessing.

• 16:31Ryan Peterman?

  In the industry, there's often deadlines, managers and all of that stuff, right? What, what's stopping a researcher from coming in at three, leaving at five, not having any output?

• 16:46Speaker 00

  There 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 thirty at the bottom, half a dozen, one like that little tree. And they would discuss

• 17:28Speaker 00

  the merit of the, the contributions of the work that was being done by the people. And they would come up with some sort of ordering, which says that you're better than I am or vice versa. How would we compare to our peers? And that would give them a sort of roughly a rank ordering, 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 looked okay or whatever. That was okay. It's like, 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?

• 18:11Speaker 00

  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 were still technically active and they were very technically knowledgeable. And then the process was repeated a couple of levels up until you had any effect or rank order in everybody. So that was kind of that, called abstract merit. You know, you know, I'm better than you are. And then there was the concrete merit phase where we've got this much money. How much do you get? How much do I get?

• 18:41Ryan Peterman?

  So there were bonuses or tied to?

• 18:44Speaker 00

  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 over all X percent. And so you will get X minus epsilon, I'll get X plus epsilon or vice versa.

• 18:57Speaker 00

  And that was once a year. And that was the whole story. But 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, Suzie did this really great thing. Let's don't forget Suzie, 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, did good stuff.

• 19:30Ryan Peterman?

  It sounds like you mentioned that their technical is like a big part of this whole system. Why is that important?

• 19:38Speaker 00

  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. If 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, but it's easier to blow smoke at somebody who is not sort of knowledgeable in your own field. But the people that you were, who are evaluating your work were exceptionally knowledgeable in the whole field.

• 20:23Speaker 00

  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.

• 20:32Ryan Peterman?

  These days, this member of technical staff title is, it's, it's almost has its own brand where it's, it's, well, it's a 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?

• 20:58Speaker 00

  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 in the modern academic role, principal investigator, whatever. And in computing, I never, would never have had somebody who helped me with my stuff.

• 21:39Speaker 00

  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 in a physical.

• 21:54Speaker 00

  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 the second level management and then there was executive director and then there was vice president, but it was very flat in that sense. Most people did not want to be promoted because that would would be seen as the end of their personal technical career that 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

• 22:36Speaker 00

  the golden era of call it the late 60s, 70s, early 80s, something like that.

• 22:42Ryan Peterman?

  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?

• 22:52Speaker 00

  Career development for myself as an individual, I never thought about it at all. I mean, I was having a good time and I was 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?

• 23:36Speaker 00

  So that you could sort of cross fertilize across the way to try and give them feedbacks or say, you know, hmm, 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, it 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.

• 24:05Ryan Peterman?

  So you mentioned you were a head 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?

• 24:19Speaker 00

  There were a handful of people I could remember who wanted to be in management. Okay, that was unusual, but there was 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

• 25:01Speaker 00

  there they had the much more traditional responsibilities of management and including looking after their people. But I think the research operation was much more a bunch of cats and you can't really herd them.

• 25:16Ryan Peterman?

  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.

• 25:24Speaker 00

  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, probably 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? Or alternatively, you know, if you don't do it now, it might never come. We'd be completely conquered.

• 26:07Speaker 00

  Or if, 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, you know, 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.

• 26:44Ryan Peterman?

  How did you know your group was so special? Because 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 Heming. So how, how did you know though, at that time, that it was such a special group?

• 27:06Speaker 00

  I think a lot of it was not so much knowing that the work they were doing was going to prove to be, prove to be in the future important, but that they were just really clearly smart and, 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. And so you could get a sense of who's doing stuff that actually matters to me. And, and so I think that was part of it. Extrapolating long-term, you know, effects, we're not very good at that, or

• 27:48Speaker 00

  I certainly wasn't figuring out who were the ones who were going to win Turing Awards. No, not really.

• 27:56Ryan Peterman?

  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, their technical chops are just untouchable?

• 28:10Speaker 00

  There's several like that. Ken Thompson's the obvious one, I think. Certainly the best programmer I've ever met, unparalleled. And the story is the first version of Unix, where he's got this little old PDP seven, which is an obsolete machine, has something like 8K 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. And he's thinking about, you know, how do you schedule disk operations so that it'll go fast and stuff like that. And his wife takes their young son off to California for three weeks and he thinks, hmm, I could do something

• 28:53Speaker 00

  here. And so in three weeks, he builds himself an editor, an assembler and an operating system. And there you have it.

• 29:00Ryan Peterman?

  By himself?

• 29:01Speaker 00

  Yeah, oh yeah, absolutely.

• 29:03Ryan Peterman?

  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?

• 29:17Speaker 00

  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, bear 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.

• 29:44Ryan Peterman?

  Oh my God.

• 29:45Speaker 00

  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 offscale good at what they do. And there were a lot of people like that at the labs.

• 30:03Speaker 00

  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 kind of thing. And so he set me to working on something and I almost instantaneously went somewhere else. And 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 it's just,

• 30:44Speaker 00

  we're, 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. And he contributed a bunch of useful software, his own Unix sort program, Doug, Unix diff program, compares two files, Doug, bunch of things of, of that sort. He did language design and development of his own. He wrote

• 31:27Speaker 00

  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. No, 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 then, 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 that he was at Bell Labs. I, I first met him in 67, I guess, and he was, until he retired, probably, probably the mid 90s, something like that.

• 32:12Ryan Peterman?

  This, this reminds me, when you mentioned department head, somewhere in my research, it might've been Heming, there was someone that you worked with who was a head of the department with no reports.

• 32:25Speaker 00

  That's Heming. Yeah. Yeah. I, I never understood that. When I first met Dick Heming, you know, he was a department head. You could tell because he had carpet on his floor. I guess he showed up and informed it that way too. But, and I couldn't figure out, you know, because I had this naive view that, you know, there was status associated with being a department head and it was totally wrong. But, but he had worked very hard to get himself a department head. So 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 in, you know, in any organization, if you're not at the right level, you may get ignored.

• 33:09Speaker 00

  And so it was harder presumably for something for people to ignore our department head than an ordinary MTS.

• 33:15Ryan Peterman?

  So he got the clout without any of the work of.

• 33:19Speaker 00

  Without the dog work and yeah, right, administering. I mean, he'd, he'd put in his dues because he, he came to labs, I think in forty six. And did a lot of early stuff with computing as 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, the research work would be done by computing, not but in physical labs. And of course they laughed at him.

• 33:53Ryan Peterman?

  In my research, I, 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.

• 34:08Speaker 00

  Oh, yeah, yeah. The AT&T did a lot of those PR films.

• 34:12Ryan Peterman?

  Yeah. And there's a, and you're, you're in the video. You're one of the first people speaking and you have your legs up on some desk and you're kind of explaining as what, what is that?

• 34:23Speaker 00

  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 Beelove, I think his name was, it 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.

• 34:58Speaker 00

  And at the time this was done, which I would guess is

• 35:03Speaker 00

  seven, late seventies, early eighties, something like that.

• 35:07Speaker 00

  Unix 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, improve people's lives or our business operations or whatever. What is Unix? And so my job in these, 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?

• 35:38Ryan Peterman?

  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?

• 35:54Speaker 00

  Well, we were, we still are.

• 35:56Ryan Peterman?

  But, but they highlight you as being a very clear communicator and a bit exceptional in your ability to convey the technical stuff you're, you're talking about. And so it's curious, like, if you have any advice on how to communicate technical work, but in such a clear way.

• 36:17Speaker 00

  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? And 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 you're not, you can adapt. It's harder when you're doing a film because you, you know, the audience is later, if at all.

• 36:49Speaker 00

  But there, there were a fair number of those things. We used to have

• 36:55Speaker 00

  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

• 37:05Speaker 00

  and 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 places, labs, so on. And Mike Lesk and I were on a regular kind 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 somewhere. Well, what are the wonders of Unix? I don't know. But one of them was that it's easy to create programs by combining programs.

• 37:47Speaker 00

  The idea of pipes where 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, uh, which was looking for spelling mistakes in a document. Because what you could do is here's a document. So let me

• 38:07Speaker 00

  collect the words in the document, get them into the lower case, 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 a one, one long pipeline, six or seven programs. So I could do this and people would sort of understand it. This is before WordPress and some software really came along.

• 38:31Speaker 00

  So I'd do this demo and people would be impressed. The high point of this.

• 38:37Speaker 00

  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.

• 38:51Speaker 00

  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, et cetera. So 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 previously. And so Colby was very impressed with this, I guess.

• 39:29Speaker 00

  It does tell you, you don't believe what you see in demos.

• 39:34Ryan Peterman?

  What's in that briefcase? Is it a bomb or a gun?

• 39:37Speaker 00

  It's got to be nuclear codes, right? I mean, I have no idea.

• 39:40Ryan Peterman?

  Interesting.

• 39:43Speaker 00

  The gentleman with this briefcase was not identified.

• 39:47Ryan Peterman?

  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.

• 39:58Ryan Peterman?

  You know, why was C so influential in your opinion, like now looking back?

• 40:03Speaker 00

  I think it hit a sweet spot in some sense of like efficiency and expressiveness.

• 40:12Speaker 00

  If you go back to when C was first created, let's just call it nineteen seventy two-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, twenty four K bytes. And that was the whole thing. So you had to write a compiler. Oh, you had an operating system. You needed a bit of space for files. What do you do? The disk, I think, was half a megabyte.

• 40:38Speaker 00

  So it's a little tricky. So C was simple enough that you could see the translation into the underlying actual instructions of the particular machine, the PDB eleven at that point. Language is simple. You could see the compilation. You could imagine building a compiler for it's forwardly enough. It 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

• 41:24Speaker 00

  no, I know expressiveness is, I think the right word. Certainly there are lots of other languages, which for various purposes are a better choice at this point.

• 41:34Speaker 00

  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? You couldn't do a lot with, uh, you know, fancy runtime stuff. You didn't want to do checking because checking would take code and you, come on, you've only got something like four K 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 class, set of things that you just don't need if you're building an operating system.

• 42:07Speaker 00

  So I think it was for its time, really, really, really good match. And then of course Unix and C was this sort of symbiosis thing 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 that people used it in preference and then they would write programs in C and they would result interesting tools. And so all of this was kind of a virtuous cycle.

• 42:37Ryan Peterman?

  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 scope tokens instead of a long-lived API key. So if something goes wrong, you can revoke one session and everything under it dies. Another feature they have is Airlock, which is an authorization layer. Every action 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.

• 43:18Ryan Peterman?

  And lastly, they have pipes, which connects your agents to over three hundred 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, that McElroy, and then there's a variety of other ones, grep. And of course there's awk. I remember I, I, I learned that a long time ago.

• 43:58Speaker 00

  Good.

• 43:58Ryan Peterman?

  Yeah.

• 44:00Ryan Peterman?

  Yeah. What's the story behind that? And, and why'd you build it?

• 44:03Speaker 00

  So this is back in the mid seventy-ish time, seventy six, seventy seven, I guess.

• 44:12Speaker 00

  Al Aho and I had been friends for a long time. Maybe he went here Princeton. He and I were undergrads at Toronto, although he was always a year ahead of me. And, and he was very interested in regular expressions, you know, 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. You know, something like that. And Peter Weinberger, I don't remember exactly how we met him.

• 44:47Speaker 00

  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 databasey flavor and report generation like RPG. From Peter and the sort of, wouldn't it be nice if strings and numbers were kind of treated. We're both first class citizens of whatever we were doing. So we thought about it for a while. And then if my memory serves, we came up with a sort of language design and then Peter went off one weekend and built it.

• 45:27Speaker 00

  Not it. Peter's extremely good programmer too. But he had the advantage of tools at that point because he could define the grammar with the Yaks, the compiler compiler that Steve Johnson had built. And the lexical part with Lex, the 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.

• 45:57Speaker 00

  And Al had the regular expression code already because that came from EGRAP.

• 46:03Speaker 00

  And you take this on one very, very good programmer over a long weekend or so, and you've got a language. Oh, 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.

• 46:21Ryan Peterman?

  A 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, I want to be able to pipe this to something that diffs, or I want to be able to. Find something and, and then you guys just build it. Is that usually how these come about?

• 46:41Speaker 00

  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 a language or something? And, and I think that's true on almost all of the little tools that you mentioned.

• 47:05Speaker 00

  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, it's.

• 47:20Speaker 00

  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.

• 47:44Speaker 00

  So, and I think all of these have that same problem. Certainly there are things in Awkward and Heinz Saget, oh my God, we should have done that better.

• 47:53Ryan Peterman?

  A lot of the, 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 grap is a really famous tool. But what's the, the story behind the namesake of that?

• 48:09Speaker 00

  Oh yeah, grap. 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 the. 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 grap.

• 48:41Ryan Peterman?

  We talked a lot about Bell Labs and, you know, you, 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?

• 48:54Speaker 00

  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. But, but you know, maybe some of the AI stuff that's going on is, is the moral equivalent at this point.

• 49:32Speaker 00

  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. And so all the fishing 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 were 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.

• 50:05Ryan Peterman?

  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, you know, grooming during the lecture?

• 50:20Speaker 00

  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, the beginning, so they'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?

• 50:53Speaker 00

  But Margot 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. And 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.

• 51:34Speaker 00

  And I got the audience to try and guide me through trimming my beard with this stuff.

• 51:42Speaker 00

  I don't remember. I think actually the hedge trimmers were plugged in, but we want to be very careful.

• 51:49Ryan Peterman?

  So you mentioned that was your first big class?

• 51:52Speaker 00

  Yes, 457.

• 51:54Ryan Peterman?

  Was public speaking nerve wracking at that time for such a large group then?

• 52:01Speaker 00

  No, I, I think originally when I was like a grad student or something, public speaking was very challenging. But I, one of the things I did first at Bell Labs and 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, I had done a bit of adjunct teaching while I was at Bell Labs earlier before the Harvard gig.

• 52:43Speaker 00

  That was by far the biggest lecture, at least more than order of magnitude, the biggest. But at that point, it's not the size of the audience so much because it's a theater performance. And David Maydon can tell you that more accurately because he's really good at it.

• 53:01Ryan Peterman?

  So if someone who is a student who's scared of public speaking asks you for advice, what would you tell them?

• 53:09Speaker 00

  I think doing it, getting into an environment where you have to talk to people and. And at least small group to begin with, and then maybe bigger one is okay.

• 53:21Speaker 00

  And I think there's no, no better way than actually just doing it, getting out there and forcing it. 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 is better because. It's a more intimate setting for the most passing over 400 people, but it's, it's a more intimate setting. And so you've got a better way to judge whether you're content, 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 direct. 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.

• 54:06Speaker 00

  But after a while, it just becomes practice and then you don't, don't worry about it.

• 54:11Ryan Peterman?

  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 LM AI stuff. I mean, unprecedented access to answers, I guess. Do you believe that LM's are a net negative or a net positive when you look at education?

• 54:36Speaker 00

  I think it's too early to tell. I can see plenty of elements of both sides of that.

• 54:42Speaker 00

  One concrete example that I have heard reported by all kinds of people around here is that students don't come to office hours.

• 54:53Speaker 00

  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.

• 55:07Speaker 00

  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:18Speaker 00

  And 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, it's not transactional that they're missing that human connection that helps

• 55:45Speaker 00

  in the future. So, so I'm sorry to see the office hours go away.

• 55:51Speaker 00

  I think a weird.

• 55:56Speaker 00

  I don't know why I called it 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. And 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.

• 56:20Ryan Peterman?

  So what percent down would you say?

• 56:24Speaker 00

  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.

• 56:50Ryan Peterman?

  Less than half?

• 56:51Speaker 00

  Yeah, maybe even down to a third. We don't know because there's a staggered way in which majors appear, but, but I would guess that if it was 200, it'll be sort of 80 ish, 90, pure guesswork, but quite a bit more. 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.

• 57:25Speaker 00

  To some extent, that's totally understandable. I think they may be overreacting, but I don't know. And if you just read the pocket of 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:50Ryan Peterman?

  All right. So the, the total number of students that go to Princeton is roughly constant?

• 57:55Speaker 00

  Oh, it's constant. It's totally constant.

• 57:56Ryan Peterman?

  But the proportion that goes to computer science.

• 57:59Speaker 00

  Different fields is different. And I don't know. I, I know those particular numbers for where did, 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.

• 58:20Ryan Peterman?

  I saw you're 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, 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:38Speaker 00

  You know, that, 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, call it 2001 ish. So they had casting call. And so a bunch of people showed up in one of the big classrooms and we 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. Okay. So this was the casting call. And then later on I got

• 59:20Speaker 00

  invitation, please come and we're going to do some shooting of the Nobel Prize ceremony.

• 59:27Speaker 00

  So you'll find me there. I can tell you where to find me. The reason you don't recognize me is first, nobody is wearing glasses. Because they would reflect. And secondly, I'm wearing black tie, something which I have never worn in my life. This is a Nobel Prize ceremony.

• 59:44Speaker 00

  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, you know, rearrange the cameras and so on.

• 1:00:09Speaker 00

  But it was really interesting and I got paid, not equity rates, but I got paid. I got something that I would have been better off to flip burgers at McDonald's for the

• 1:00:19Speaker 00

  and then the movie came out and, and it was fine. But the wonderful thing is that I got an Erdish Bacon number of five.

• 1:00:25Ryan Peterman?

  Erdish Bacon. So, okay. What those numbers represent, how far you are from those people in your cited works?

• 1:00:33Speaker 00

  In, in, in their related work. So my, my Erdish number is three, because I can go through several people, a couple of paths to Erdish in steps, three steps. But my Bacon number is two, because I was in this film with somebody who was in a film with, with Kevin Bacon.

• 1:00:50Speaker 00

  So anyway, that's the, the, the gist of it. I actually met John Nash a number of times after that.

• 1:00:56Ryan Peterman?

  The, not the actor, the real?

• 1:00:58Speaker 00

  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, I don't remember how it came about, but I was giving a talk to an internal group in the mass department about something that I had worked on. I'd forgotten what it was. And I was, you know, into this, I'd been going 10 minutes or something. I was on a roll and I'm not scared of audiences or anything. So I had a good time and John Nash walked in.

• 1:01:32Speaker 00

  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.

• 1:01:42Speaker 00

  But that, that's one of the few times where public speaking is a bit of a threat.

• 1:01:48Ryan Peterman?

  Another interesting factoid that I wasn't sure if this is true, but so in the, the Git repo for the Go programming language. Actually, the first commit in it is from you in 1972 supposedly. But the, you know, the programming language started in 2008.

• 1:02:10Speaker 00

  Yeah, right. I have no idea what this is.

• 1:02:13Ryan Peterman?

  Okay. You've never seen?

• 1:02:14Speaker 00

  This is news to me.

• 1:02:16Ryan Peterman?

  Okay. Yeah. It's supposedly, I mean, I found it says first commit to the Go Git repo.

• 1:02:23Speaker 00

  Oh, is it a whole world example? That's the B program.

• 1:02:26Ryan Peterman?

  Yeah, yeah, yeah. It's, it's in B for some reason.

• 1:02:30Speaker 00

  So.

• 1:02:32Ryan Peterman?

  And this is followed up by commit 1974 to convert it to C. And then another one to convert to NCS. So maybe Robert copied your Hello World repo and used it to start going.

• 1:02:44Speaker 00

  I never used Git at that point. I don't think I started using Git until maybe 10 years ago.

• 1:02:50Ryan Peterman?

  Interesting. So then, what did you use? Was there the notion of version control back then? Cause somehow?

• 1:02:57Speaker 00

  Version control came along in the mid seventies. There was something done by the programmers work, 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 Tici, which was a variant of the same thing, revision control system. And then there was CBS, was it concurrent, concurrent version system or something like that? And then some other version of it and then get and, and, 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:42Ryan Peterman?

  Interesting. Okay. Yeah. I guess it'll just remain a mystery. Maybe, maybe Robert can answer or something if I ever interview him. In your memoir, there's a thank you to Grace Emlen. 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 Emlen, it said. Relocated Witness Protection Program. And so curious what what that is about.

• 1:04:18Speaker 00

  There was this period of time.

• 1:04:22Speaker 00

  Forgotten the dates when Bell Labs decided that employees had to have. They 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. And one of the bits of insurrection was the creation of badges that were fakes. And so Grace Emlen was a creation of.

• 1:05:00Speaker 00

  I think it was probably Fred Gramp who did it. There's this gremlin thing and so G R Emlen Grace. And we managed to get Grace into a variety of official records for the company for a while and and she. This little gremlin like thing, you know, this high sat 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.

• 1:05:32Speaker 00

  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. So I wore this badge all over the place. I wore it when I met Bill Gates at one point. I don't think he noticed either.

• 1:05:47Speaker 00

  And so, you know, people didn't take kindly to bureaucratic stuff, even though probably badges were a fine idea.

• 1:05:56Ryan Peterman?

  Was the badging system digital at that?

• 1:06:00Speaker 00

  No, no, it was just paper, pieces of paper.

• 1:06:02Ryan Peterman?

  Okay.

• 1:06:03Speaker 00

  Or they were pieces of plastic, but you could put your own paper in front of it.

• 1:06:08Ryan Peterman?

  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's passwords 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.

• 1:06:46Speaker 00

  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 I guess you're probably right. It probably was either DES or some World War Two machine, like a Hagelin machine or whatever that the crypt 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? And 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.

• 1:07:28Speaker 00

  And so I don't know, somebody must have copied the password file from the research Unix things at Bell Labs over to some Berkeley system. Don't know how it got there.

• 1:07:39Ryan Peterman?

  Coming to the end, you know, 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?

• 1:07:55Speaker 00

  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 rewarding 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. It's you're you're not, you won't meet most of the people who might look at a book. But with luck, they will also learn something from it.

• 1:08:30Speaker 00

  Partly, it's a way to learn the stuff yourself. And, you know, 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 still doing it. This is your chance to do a commercial announcement.

• 1:08:59Ryan Peterman?

  Yeah, what's your latest book?

• 1:09:00Speaker 00

  Yeah, so I I did a book over the last year or so, a history book called Important Ideas in Computing. And it will appear from MIT Press in January, end of commercial announcement.

• 1:09:13Ryan Peterman?

  Is is that the memoir? Oh, no, this hasn't come out yet.

• 1:09:16Speaker 00

  Yeah, this hasn't come out yet. Over there underneath your camera is the cover of it.

• 1:09:21Ryan Peterman?

  Of shifts?

• 1:09:22Speaker 00

  Yeah, right.

• 1:09:23Ryan Peterman?

  Okay.

• 1:09:24Speaker 00

  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 Kieran idea, but it's not really quite. But, you know, the shift from analog to digital. Big difference. I mean, all the camera stuff you're doing here would not be feasible with film, right?

• 1:09:49Speaker 00

  And so there's this stored program computer, the idea that you can build one general person's 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 what you're doing here wouldn't be possible. All our computers wouldn't be.

• 1:10:16Speaker 00

  Programming languages, you know, if we were still writing assembly language, it would be pretty bad. But the evolution of programming languages is making it ever easier to tell 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. It'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 models. 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. So my wife, who is not a computer person.

• 1:10:59Speaker 00

  Is interested in learning more about what's going on with artificial intelligence, large language models, explain this, what's that mean? What's 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.

• 1:11:18Ryan Peterman?

  Yeah. The, you know, with with this this AI and, you know, 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 could say a hundred percent of the code in the last so many months. Was written by an LM. And so a lot of people who really love 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.

• 1:12:01Ryan Peterman?

  Maybe like the punch cards or I don't know, something like that. And I guess, how did you feel at that time?

• 1:12:07Speaker 00

  Yeah, well, I don't miss punch cards in the slightest.

• 1:12:11Speaker 00

  No way. I was I was thinking, you know, my my thesis was done on my PhD thesis was done on punch cards. And that was three boxes of cards. And I realized if that was 30 pounds of stuff I had to carry around for my thesis. So that's, so there are 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 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 and sort of rethink and relearn, you know. That's what pointers are all about, kind of same.

• 1:12:56Speaker 00

  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? Claude or whatever to generate it for you? I don't think so. I don't think that at all. And 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? Or should you have wanted something different? And all of those sorts of things.

• 1:13:39Speaker 00

  And that's in an environment where you know what you're doing. I've been using mostly Claude, but others as well.

• 1:13:49Speaker 00

  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 we, if we already knew the answer, we wouldn't need it. And so I'm wrestling with that and my observation is.

• 1:14:31Speaker 00

  Ninety percent of the time it generates a perfectly fine query and 10% of the time it doesn't. Gives you a totally wrong answer and I don't know which is which.

• 1:14:40Ryan Peterman?

  It sounds like what you're saying is you need some domain expertise, otherwise you can't be the judge of it.

• 1:14:45Speaker 00

  Yeah, 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 AI again to help you with generating the test, but 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. Now I'm oversimplifying and I'm not a high powered user and I know plenty of people who were, as you described her of, you know, essentially everything they used to do, they have outsourced to something like a large language model.

• 1:15:28Speaker 00

  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. And I, I don't, 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?

• 1:16:10Speaker 00

  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 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, you know, thrive in this brave new world. And the short answer is I have no idea either. And I don't think anywhere it does.

• 1:16:47Ryan Peterman?

  In the world you described, 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?

• 1:17:05Speaker 00

  Well, I mean, first you, 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.

• 1:17:20Speaker 00

  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. We trust our compilers and in fact, we can 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, you know, 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

• 1:18:02Speaker 00

  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. And 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.

• 1:18:27Ryan Peterman?

  When, when C came out, were people mourning assembly language?

• 1:18:32Speaker 00

  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 were working on Fortran. This would be roughly 56, 57, that kind of period, I guess.

• 1:18:52Speaker 00

  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 elegance and so on. And aimed towards efficiency of the translation. And, 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.

• 1:19:37Speaker 00

  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'd never learn, you know, I have a 70, 90 assembly language. And furthermore, if you got it working once, you could put it on multiple different machines.

• 1:19:59Ryan Peterman?

  When you look across your whole career, because you, 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?

• 1:20:15Speaker 00

  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 in OC.

• 1:20:22Speaker 00

  Kind of silly, but okay. At least I know it. If I were to write bigger ones, I would almost surely write them in Python because for many things, that's the right compromise. It's certainly efficient enough for anything I do. And it's totally expressive for the kinds of things I might want to do. I 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. Are there languages I wouldn't use? So who shall I insult today?

• 1:20:58Speaker 00

  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.

• 1:21:08Speaker 00

  It was a simple program. You would take text input lines of arbitrary lengths and put them out so that the lines were all at most 60 characters or something. So it's a simple minded version of the reflow that you would see in a, in a browser. And I would write it in every language I could lay my hands on. I had two dozen or more of them and I'd 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 OC 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.

• 1:21:50Speaker 00

  And the other scripting languages like Perl and Python and PHP and they were variously sort of okay. Perl was always the faster one.

• 1:22:01Speaker 00

  And some of the high powered languages that were supposed to be better were actually slower. Java was slower than the scripting languages. Kind 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, you know, look at the manual, oh, I see, done.

• 1:22:27Speaker 00

  Whereas Haskell took forever. And then I showed it to some Haskell expert and he said, oh, but you have to import this character library that does this and you're in, and then it ran faster.

• 1:22:36Ryan Peterman?

  What made Haskell take so long?

• 1:22:38Speaker 00

  It's a different way of thinking. And I just didn't grow it. I really didn't. And, and I think part of it was the, the problem is you're taking input in one form and async, not asynchronously, but not at the same cycle. You're trying to produce outputs. So your lines are varying lengths and you run through 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.

• 1:23:14Ryan Peterman?

  I saw somewhere on the internet that somewhat recently in the vast, the last few years, you added Unicode to OC or the repo of OC that you're kind of contributing to. And it made me think, what motivates you to continue to write code?

• 1:23:33Speaker 00

  Well, it's fun. It's this intellectual challenge that we talked about. And I think part of it was that for OC 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 eight. So I would, I wanted OC 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, OC was very clunky for processing that. And so added a mechanism so that you could say, hey, do CSV properly and the input mechanism.

• 1:24:16Speaker 00

  I think both of those were triggered probably by working on a second edition of the OC 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.

• 1:24:28Ryan Peterman?

  For young people, a lot of times they're, they're trying to discover,

• 1:24:34Ryan Peterman?

  I guess their passion or the, the thing they want to work on. It sounds like you 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? What would you say?

• 1:24:54Speaker 00

  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 sit in your room and think about it. You go to parties or whatever, or maybe you use some app like Tinder or I don't know.

• 1:25:14Speaker 00

  But 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 imperfect 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.

• 1:25:32Speaker 00

  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.

• 1:25:46Speaker 00

  Not to drugs, presumably.

• 1:25:49Speaker 00

  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. Be careful if you get it from me.

• 1:26:15Ryan Peterman?

  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?

• 1:26:31Speaker 00

  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 bounds. And so I'm like a ball dropped into a galton board and, you know, and I come out somewhere at 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, one, I think genuinely useful observation, a lot of this stuff comes from talking with Dick Hamming. But but it was Pester who said, chance favors the prepared mind.

• 1:27:16Speaker 00

  So the more things you have thought about, you've 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.

• 1:27:27Ryan Peterman?

  On that board, you're saying, prepared mind kind of bias those outcomes a little?

• 1:27:33Speaker 00

  Towards a potentially better outcome. Yeah, I think so.

• 1:27:37Ryan Peterman?

  Well, yeah, that's all my questions. Thank you so much for your time. Really appreciate it.

• 1:27:40Speaker 00

  My pleasure.

• 1:27:42Ryan Peterman?

  Hey, thank you for watching this podcast. 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 Liskoff, Mike Stonebreaker, Mark Booker. 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 building the tooling now.

• 1:28:25Ryan Peterman?

  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.