- So what's to you, so you wrote a book, C Programming Language, and C is probably one of the most important languages in the history of programming languages, if you kind of look at impact. What do you think is the most elegant or powerful part of C? Why did it survive?

Why did it have such a long-lasting impact? - I think it found a sweet spot of expressiveness. So you could rewrite things in a pretty natural way, and efficiency, which was particularly important when computers were not nearly as powerful as they are today. You've got to put yourself back 50 years, almost in terms of what computers could do, and that's roughly four or five generations, decades of Moore's law, right?

So expressiveness and efficiency, and I don't know, perhaps the environment that it came with as well, which was Unix. So it meant if you wrote a program, it could be used on all those computers that ran Unix, and that was all of those computers, because they were all written in C, and that way, Unix, the operating system itself, was portable, as were all the tools.

So it all worked together, again, in one of these things where things fed on each other in a positive cycle. - What did it take to write sort of a definitive book, probably definitive book on all of programming, like it's more definitive to a particular language than any other book on any other language, and did two really powerful things, which is popularized the language, at least from my perspective, maybe you can correct me, and second is created a standard of how, how this language is supposed to be used and applied.

So what did it take? Did you have those kinds of ambitions in mind when working on that? - Is this some kind of joke? (laughing) No, of course not. So it's an accident of timing, skill, and just luck. - A lot of it is, clearly, timing was good. Now, Dennis and I wrote the book in 1977.

- Dennis Ritchie. - Yeah, right. And at that point, Unix was starting to spread. I don't know how many there were, but it would be dozens to hundreds of Unix systems, and C was also available on other kinds of computers that had nothing to do with Unix, and so the language had some potential.

And there were no other books on C, and Bell Labs was really the only source for it, and Dennis, of course, was authoritative because it was his language, and he had written the reference manual, which is a marvelous example of how to write a reference manual. Really, really, very, very well done.

So I twisted his arm until he agreed to write a book, and then we wrote a book. And the virtue, or advantage, at least, I guess, of going first is that then other people have to follow you if they're gonna do anything. And I think it worked well because Dennis was a superb writer.

I mean, he really, really did. And the reference manual in that book is his, period. I had nothing to do with that at all. So just crystal clear prose, very, very well expressed. And then he and I, I wrote most of the expository material, and then he and I sort of did the usual ping-ponging back and forth, refining it.

But I spent a lot of time trying to find examples that would sort of hang together and that would tell people what they might need to know at about the right time that they should be thinking about needing it. And I'm not sure it completely succeeded, but it mostly worked out fairly well.

- What do you think is the power of example? I mean, you're the creator, at least one of the first people to do the Hello World program, just like the example. If aliens discover our civilization hundreds of years from now, it'll probably be Hello World programs, just like a half-broken robot communicating with them with a Hello World.

So what, and that's a representative example. So what do you find powerful about examples? - I think a good example will tell you how to do something, and it will be representative of, you might not want to do exactly that, but you will want to do something that's at least in that same general vein.

And so a lot of the examples in the C book were picked for these very, very simple, straightforward text processing problems that were typical of Unix. I want to read input and write it out again. There's a copy command. I want to read input and do something to it and write it out again.

There's a grab. And so that kind of find things that are representative of what people want to do and spell those out so that they can then take those and see the core parts and modify them to their taste. And I think that a lot of programming books that I, I don't look at programming books a tremendous amount these days, but when I do, a lot of them don't do that.

They don't give you examples that are both realistic and something you might want to do. Some of them are pure syntax. Here's how you add three numbers. Well, come on, I could figure that out. Tell me how I would get those three numbers into the computer and how we would do something useful with them.

And then how I put them back out again, neatly formatted. - And especially if you follow that example, there is something magical of doing something that feels useful. - Yeah, right. And I think it's the attempt, and it's absolutely not perfect, but the attempt in all cases was to get something that was going to be either directly useful or would be very representative of useful things that a programmer might want to do.

But within that vein of fundamentally text processing, reading text, doing something, writing text. (laughs) (upbeat music) (upbeat music) (upbeat music) (upbeat music) (upbeat music) (upbeat music) you