YouSaid · the spoken record

Brian Kernighan

lines on the record: 121
first: 2020-07-18
most recent: 2020-07-18
sittings or episodes: 1
sources: podcast

Every line below is reproduced as it was said and linked to the record it came from. Nothing here is summarised or generated. Directory · Search · Corrections

“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.”
2020-07-18 · Lex Fridman Podcast · #109 – Brian Kernighan: UNIX, C, AWK, AMPL, and Go Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“Out 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 I would do something useful with them and then how I put them back out again neatly formatted.”
2020-07-18 · Lex Fridman Podcast · #109 – Brian Kernighan: UNIX, C, AWK, AMPL, and Go Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“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 fine things that are representative of what people want to do and spell those out so that they can then take those and see the core parts and modify them to their taste. And I think that a lot of programming books that I don't look at programming books are tremendous.”
2020-07-18 · Lex Fridman Podcast · #109 – Brian Kernighan: UNIX, C, AWK, AMPL, and Go Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“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 and 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.”
2020-07-18 · Lex Fridman Podcast · #109 – Brian Kernighan: UNIX, C, AWK, AMPL, and Go Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“And there were no other books on sea and Bellabs 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. The virtue or advantage, at least, I guess, of going first is that then other people have to follow you if they're going to do anything. And I think it worked well because”
2020-07-18 · Lex Fridman Podcast · #109 – Brian Kernighan: UNIX, C, AWK, AMPL, and Go Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“Of it is clearly timing was good. Dennis and I wrote the book in 1977. 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.”
2020-07-18 · Lex Fridman Podcast · #109 – Brian Kernighan: UNIX, C, AWK, AMPL, and Go Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“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 was Unix, the operating system itself was portable as were all the tools. So it all worked together again in one of these things where things fed on each other in a positive cycle.”
2020-07-18 · Lex Fridman Podcast · #109 – Brian Kernighan: UNIX, C, AWK, AMPL, and Go Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“It's a different flavor of what they're doing. They're much more in touch with the actual machine, but in a positive way. That is, you can talk about memory in a more controlled way. You can talk about the different data types that the machine supports in a way and more ways to structure and organize data. And so the system programming languages, there was a lot of effort in that in the call it the late 60s, early 70s. C is, I think, the only real survivor of that. And then what happens after that, you get things like object-oriented programming languages? Because as you write programs in a language like C, at some point scale gets to you and it's too hard to keep track of the pieces and there's no guardrails or training wheels or something like that to prevent you from doing bad things. So C++ comes out of that tradition.”
2020-07-18 · Lex Fridman Podcast · #109 – Brian Kernighan: UNIX, C, AWK, AMPL, and Go Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“Programs that programming languages that would take on the kinds of things that were necessary to write so-called system programs, things like text editors or assemblers or compilers or operating systems themselves, those kinds of things.”
2020-07-18 · Lex Fridman Podcast · #109 – Brian Kernighan: UNIX, C, AWK, AMPL, and Go Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“Anybody who wants is willing to invest some time in learning a programming language and is not then tied to a particular kind of computer. And then in the 70s, you get system programming languages of which C is the survivor.”
2020-07-18 · Lex Fridman Podcast · #109 – Brian Kernighan: UNIX, C, AWK, AMPL, and Go Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“Fortran probably. Oh, yeah. Cobalt, too. But the deal was that once you moved up that level, then you, let's call it Fortran, you had a language that was not tied to a particular kind of hardware because a different compiler would compile for different kind of hardware. And that meant two things. It meant you only had to write the program once, which was very important. And it meant that you could, in fact, if you were a random engineer, physicist, whatever, you could write that program yourself. You didn't have to hire a programmer to do it for you. might not be as good as you'd get with the real programmer, but it was pretty good. And so it democratized and made much more broadly available the ability to write code.”
2020-07-18 · Lex Fridman Podcast · #109 – Brian Kernighan: UNIX, C, AWK, AMPL, and Go Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“What we stood for. Whereas Cobal, which is the common business oriented language that Grace Hopper and others worked on, which was aimed at business kinds of tasks. There was algol, which was mostly meant to describe algorithmic computations, I guess you could argue basic was in there somewhere. I think it's just a little later. And so, all of those moved the level up. And so they were closer to what you and I might think of as we were trying to write a program. And they were focused on different domains, Fortran for formula translation, engineering computations, let's say COBOL for business, that kind of thing.”
2020-07-18 · Lex Fridman Podcast · #109 – Brian Kernighan: UNIX, C, AWK, AMPL, and Go Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“Right, they have exactly, in their simplest form, at least, one instruction language instruction per instruction in the machine's repertoire. And so you have to know the machine intimately to be able to write programs in it. And if you write an assembly language program for one kind of machine and then you say, geez, it's nice. I'd like it in a different machine, start over. Okay. So very bad. And so what happened in the late 50s was people realized you could play this game again and you could move up a level in writing or creating languages that were closer to the way that real people might think about how to write code. There were, I guess, arguably three or four at that time period. There was Fortran, which came from IBM, which was formula translation, meant to make it easy to do scientific and engineering computation.”
2020-07-18 · Lex Fridman Podcast · #109 – Brian Kernighan: UNIX, C, AWK, AMPL, and Go Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“So assembly languages then, let's call that the early 1950s. And so every different flavor of computer has its own assembly language. So the EDSAC had its, and a Manchester had its, and the IBM whatever 70, 90, or 704 or whatever had its, and so on. So everybody had their own assembly langu”
2020-07-18 · Lex Fridman Podcast · #109 – Brian Kernighan: UNIX, C, AWK, AMPL, and Go Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“Basically, write a program that would convert mnemonics like add ADD into whatever the bit pattern was that corresponded to an add instruction. And they would do the clerical work of figuring out where things were so you could put a name on a location in a program and the assembler would figure out where that corresponded to when the thing was all put together and dropped into memory. Early on, and this would be the late 40s and very early 50s, there were assemblers written for the various machines that people used. You may have seen in the paper just a couple days ago, Tony Burker died. He did this thing in Manchester called autocode, a language which I knew only by name. But it sounds like it was a flavor of assembly language, sort of a little higher in some ways. And it replaced a language that Alan Turing wrote, which you put in zeros and ones, but you put in backwards order.”
2020-07-18 · Lex Fridman Podcast · #109 – Brian Kernighan: UNIX, C, AWK, AMPL, and Go Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“So, I guess you could say programming languages started probably in what the late 40s or something like that. People used to program computers by basically putting in zeros and ones using something like switches on a console and then or maybe holes and paper tapes, something like that. So extremely tedious, awful, whatever. And so I think the first programming languages were... Relatively crude assembly languages where people would”
2020-07-18 · Lex Fridman Podcast · #109 – Brian Kernighan: UNIX, C, AWK, AMPL, and Go Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“It is available. You have to download it yourself from typically the Plan 9 operating system distribution. It's been maintained by people there.”
2020-07-18 · Lex Fridman Podcast · #109 – Brian Kernighan: UNIX, C, AWK, AMPL, and Go Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“Without printing. And there were a number of editors there, the one that I was most familiar with and still use is VI, which was done by Bill Joy. And so that dates from probably the late 70s as a guess. Took it full advantage of the cursor controls. I suspect that Emacs was roughly at the same time, but I don't know. I've never internalized Emacs. So I use, at this point, I stopped using ED, although I still can. I use VI sometimes, and I use SAM when I can.”
2020-07-18 · Lex Fridman Podcast · #109 – Brian Kernighan: UNIX, C, AWK, AMPL, and Go Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“When CRT displays came along, he Then you could start to use cursor control and you could sort of move where you were on the screen in.”
2020-07-18 · Lex Fridman Podcast · #109 – Brian Kernighan: UNIX, C, AWK, AMPL, and Go Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“Work on any part of it, the whole thing, or whatever, but it was entirely command line based, and it was entirely on paper. Paper. And that meant that you changed. Yeah, right. Real paper. And so if you changed the line. You had to print that line using up another line of paper to see what change caused. Okay. So when”
2020-07-18 · Lex Fridman Podcast · #109 – Brian Kernighan: UNIX, C, AWK, AMPL, and Go Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“You could edit it. The usual thing that you would get in an editor. And Ken Thompson wrote an editor called QED, which was very, very powerful. But these were all totally a command-based. They were not most or cursor-based because it was before mice and even before cursors because they were running on terminals that printed on paper. Okay, no CRT type displays, let alone LEDs. And so Then when Unix came along, Ken took QED and stripped it way, way, way, way down. And that became an editor that he called ED. It was very simple, but it was a line-oriented editor. And so you could load a file and then you could talk about the lines one through the last line and you could print ranges of lines. You could add text. You could delete text. You could change text, or you could do a substitute command that would change things within a line or within groups of lines.”
2020-07-18 · Lex Fridman Podcast · #109 – Brian Kernighan: UNIX, C, AWK, AMPL, and Go Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“So in ancient times, like call it the first time sharing systems going back to what we were talking about, there were editors, there was an editor on CTSS that I don't even remember what it was called. It might have been edit, where you could type text, program text, and it would do something, or document text.”
2020-07-18 · Lex Fridman Podcast · #109 – Brian Kernighan: UNIX, C, AWK, AMPL, and Go Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“Yeah, perfect is too strong a word. It's way too strong a word. What I use by default, I have at this point a 13-inch MacBook Air, which I use because it's kind of a reasonable balance of the various things I need. I can carry it around. It's got enough computing horsepower, screens big enough, keyboard's okay. And so I basically do most of my computing on that. I have a big IMAC in my office that I use from time to time as well, especially when I need a big screen, but otherwise tends not to be used as much. You use mostly SAM, which is an editor that Rob Pike wrote long ago at Bell Labs and”
2020-07-18 · Lex Fridman Podcast · #109 – Brian Kernighan: UNIX, C, AWK, AMPL, and Go Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“Have no idea, but there have been things like that for long. Sigwin, for example, which is a wonderful collection of take all your favorite tools from Unix and Linux and just make them work perfectly on Windows. And so that's something that's been going on for at least 20 years, if not longer. And I use that on my one remaining Windows machine. Routinely because if you're doing something that is batch computing suitable for command line, that's the right way to do it because the Windows equivalents are, if nothing else not familiar to me.”
2020-07-18 · Lex Fridman Podcast · #109 – Brian Kernighan: UNIX, C, AWK, AMPL, and Go Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“Don't know, and it's not strictly unique, but it's certainly focused there. And I think some of it's the weight of history that Windows came from MS-DOS. MS-DOS was a pretty pathetic operating system, although common on unboundedly large number of machines, but somewhere in roughly the 90s Windows became a graphical system. And I think Microsoft spent a lot of their energy on making that graphical interface what it is. And that's a different model of computing. It's a model of computing where you point and click and sort of experiment with menus. It's a model of computing works rather well for people who are not programmers. I just want to get something done, whereas teaching something like the command line to non-programmers turns out to sometimes be an uphill struggle. And so I think Microsoft probably was right in what they did. Now you mentioned...”
2020-07-18 · Lex Fridman Podcast · #109 – Brian Kernighan: UNIX, C, AWK, AMPL, and Go Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“In some sense, yeah, right, because So, Grep is it basically searches the input for particular patterns, regular expressions technically of a certain class. And it has that same paradigm that OC does. It's a pattern action thing. It reads through all the files and then all the lines in each file, but it has a single pattern, which is the regular expression you're looking for, and a single action printed if it matches. So in that sense, it's a much simpler version, and you could write crap in awk as a one-liner. I use probably more than anything else at this point just because it's so convenient and natural”
2020-07-18 · Lex Fridman Podcast · #109 – Brian Kernighan: UNIX, C, AWK, AMPL, and Go Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“About it, and it collects information, it goes along. Like, what line are we on? How many fields are there on this line? So lots of things that just make it so that a program which in another language, let's say Python, would be five, 10, 20 lines in Aukus one or two lines.”
2020-07-18 · Lex Fridman Podcast · #109 – Brian Kernighan: UNIX, C, AWK, AMPL, and Go Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“I think it's mostly the selection of default behaviors that you sort of hinted at a moment ago. What AC does is to read through a set of files and then within each file it reads through each of the lines and then on each of the lines it has a set of patterns that it looks for that's your auct program and if one of the patterns matches there is a corresponding action that you might perform and so it's kind of a quadrupedly nested loop or something like that and that's all completely automatic. You don't have to say anything about it. You just write the pattern and the action and then run the data by it. And so that paradigm for programming is very natural and effective one. And I think we captured that reasonably well in AWC. And it does other things for free as well. It splits the data into fields so that on each line there are fields separated by whitespace or something. And so it does that for free. You don't have to say anything.”
2020-07-18 · Lex Fridman Podcast · #109 – Brian Kernighan: UNIX, C, AWK, AMPL, and Go Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“Yeah, it's very good for that kind of thing, that's sort of what it was meant for, I think what we didn't appreciate was that the model was actually quite good for a lot of data processing kinds of tasks and that it's kept going as long as it has because at this point it's over 40 years old and it's still, I think, a useful tool. Well, this is paternal interest, I guess, but I think in terms of programming languages, you get the most bang for the buck by learning awk. And it doesn't scale the big programs, but it does pretty darn well on these little things where you just want to see all the somethings in something. And so, yeah, I find I probably write more awk than anything else at this point.”
2020-07-18 · Lex Fridman Podcast · #109 – Brian Kernighan: UNIX, C, AWK, AMPL, and Go Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“So Awk is a scripting language that was done by myself Leaho and Peter Weinberger. We did that originally in the late 70s. It was a language that was meant to make it really easy to do quick and dirty tasks like counting things or selecting interesting information from basically all text files, rearranging it in some way or summarizing it.”
2020-07-18 · Lex Fridman Podcast · #109 – Brian Kernighan: UNIX, C, AWK, AMPL, and Go Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“Better up to call it a few hundred lines or something like that. And it's been a long time since I wrote programs that were much more than that.”
2020-07-18 · Lex Fridman Podcast · #109 – Brian Kernighan: UNIX, C, AWK, AMPL, and Go Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“It's certainly much more the informal incremental. First, I don't write big programs at this point. It's been a long time since I wrote a program that was more than I call it a few hundred or more lines, something like that. Many of the programs I write are experiments for either something I'm curious about or often for something that I want to talk about in a class. And so those necessarily tend to be relatively small. A lot of the kind of code I write these days tends to be for sort of exploratory data analysis where I've got some collection of data and I want to try and figure out what on earth is going on in it. And for that, those programs tend to be very small. Sometimes you're not even programming. You're just using existing tools like counting things or sometimes you're writing awk scripts because two or three lines will tell you something about a piece of data. And then when it gets bigger, well, then I will probably write something in Python because that scales.”
2020-07-18 · Lex Fridman Podcast · #109 – Brian Kernighan: UNIX, C, AWK, AMPL, and Go Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“Same as science because engineering you're working with constraints. You have to figure out not only what is a good algorithm for this kind of thing, but what's the most appropriate algorithm given the amount of time we have to compute, the amount of time we have to program, what's likely to happen in the future with maintenance, who's going to pick this up in the future, all of those kind of things that if you're an engineer, you get to worry about. Whereas if you think of yourself as a scientist, well, you can maybe push them over the horizon in a way. And if you're an artist, what's that?”
2020-07-18 · Lex Fridman Podcast · #109 – Brian Kernighan: UNIX, C, AWK, AMPL, and Go Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“I think it's some of each. It's some combination. Some of the art is figuring out what it is that you really want to do. What should that program be? What would make a good program? And that's some understanding of what the task is, what the people who might use this program want. And I think that's art in many respects. The science part is trying to figure out how to do it well. And some of that is real computer science-y stuff. Like what algorithm should we use at some point? Mostly in the sense of being careful to use algorithms that will actually work properly, scale properly, avoiding quadratic algorithms when a linear algorithm should be the right thing. That kind of more formal view of it. Same thing for data structures, but also it's, I think, an engineering field as well. And engineering is not quite the same.”
2020-07-18 · Lex Fridman Podcast · #109 – Brian Kernighan: UNIX, C, AWK, AMPL, and Go Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“In effect, files in a file system. And the Plan 9 operating system, which came along, I guess, in the late 80s or something like that, took a lot of those ideas from the original Unix and tried to push the generalization even further so that in Plan 9, a lot of different resources are file systems. They all share that interface. So that would be one example where finding the right model of how to do something means that an awful lot of things become simpler. And it means, therefore, that more people can do useful, interesting things with them without having to think as hard about it.”
2020-07-18 · Lex Fridman Podcast · #109 – Brian Kernighan: UNIX, C, AWK, AMPL, and Go Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“I think part of the reason for efficiency was that it began on extremely modest hardware, very, very, very tiny, and so you couldn't get carried away. You couldn't do a lot of complicated things. Because you just didn't have the resources, either processor speed or memory. And so that enforced a certain minimality of mechanisms and maybe a search for generalizations so that you would find one mechanism that served for a lot of different things rather than having lots of different special cases. I think the file system in Unix is a good example of that. The file system interface and its fundamental form is extremely straightforward. And that means that you can write code very, very effectively for the file system. And then one of those generalizations is that, gee, that file system interface works for all kinds of other things as well. And so in particular, the idea of reading and writing to devices is the same as reading and writing to a disk that has a file system. And then that gets carried further in other parts of the world processes become”
2020-07-18 · Lex Fridman Podcast · #109 – Brian Kernighan: UNIX, C, AWK, AMPL, and Go Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“Right, and a very, very, very large number of universities had the license and they were able to talk to all the other universities who had the license. Technically not open, technically belonging to ATT pragmatically pretty open.”
2020-07-18 · Lex Fridman Podcast · #109 – Brian Kernighan: UNIX, C, AWK, AMPL, and Go Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“I guess the open source movement might have started when Richard Stallman started to think about this in the late 80s. And by 1991, when Torvalds decided he was going to do a Unix-like operating system, there was enough expertise that in the community that first he had a target. He could see what to do because the kind of the Unix system call interface and the tools and so on were there. And so he was able to build an operating system that at this point, when you say Unix, in many cases what you're really thinking is Linux.”
2020-07-18 · Lex Fridman Podcast · #109 – Brian Kernighan: UNIX, C, AWK, AMPL, and Go Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“I think that's a mischaracterization in the sense. It absolutely was not open source. It was very definitely proprietary, licensed, but it was licensed freely to universities in source code form. For many years. And because of that, generations of university students and their faculty people grew up knowing about Unix and there was enough expertise in the community that it then became possible for people to kind of go off in their own direction and build something that looked Unix-like. The Berkeley version of Unix started with that licensed code and gradually picked up enough of its own code contributions, notably from people like Bill Droy, that eventually it was able to become completely free of any AT&T code. In other words, an enormous amount of legal jockeying around this in the late early to late 80s, early 90s, something like that. And then...”
2020-07-18 · Lex Fridman Podcast · #109 – Brian Kernighan: UNIX, C, AWK, AMPL, and Go Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“I think that's very nice, but in a sense, it's survivor bias. And if it hadn't happened at Bell Labs, there were other places that were doing really interesting work as well, Xerox Park is perhaps the most obvious one. Xerox Park contributed enormous amount of good material. And many of the things we take for granted today in the same way came from Xerox Park experience. I don't think they capitalized in the long run as much their parent company was perhaps not as lucky in capitalizing on this. Who knows? But that's certainly another place where there was a tremendous amount of influence. There were a lot of good university activities. MIT was obviously no slouch in this kind of thing and others as well.”
2020-07-18 · Lex Fridman Podcast · #109 – Brian Kernighan: UNIX, C, AWK, AMPL, and Go Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“Offices are nearby Yeah, yeah. No, Bell Ebs was fundamentally one giant building, and most of the people were involved in this Unix stuff. We're in two or three quarters, and there was a room, oh, how big was it, probably call it 50 feet by 50 feet, make up a number of that, which had some access to computers there as well as in offices and people hung out there and it had a coffee machine. And so there was, it was mostly very physical. We did use email, of course. But it was fundamentally for a long time all on one machine. So there was no need for internet.”
2020-07-18 · Lex Fridman Podcast · #109 – Brian Kernighan: UNIX, C, AWK, AMPL, and Go Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“Certainly before the internet, it was mostly physical right there, you know, somebody who came into your office and say something.”
2020-07-18 · Lex Fridman Podcast · #109 – Brian Kernighan: UNIX, C, AWK, AMPL, and Go Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“In many cases still exist today, and I think that was part of what made it fun because programming itself is fun. It's puzzle solving in a variety of ways. But I think it's even more fun when you do something that somebody else then uses. Even if they whine about it not working, the fact that they used it is part of the reward mechanism.”
2020-07-18 · Lex Fridman Podcast · #109 – Brian Kernighan: UNIX, C, AWK, AMPL, and Go Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“It was a blast, it really was I like to program. I'm not a terribly good programmer, but it was a lot of fun to write code. And in the early days, there was an enormous amount of what you would today, I suppose, call low hanging fruit. People hadn't done things before. And this was this new environment. And the whole combination of nice tools and very responsive system and tremendous colleagues made it possible to write code. You could have an idea in the morning. You could do an experiment with it. You could have something limping along that night or the next day and people would react to it and they would say, oh, that's wonderful, but you're really screwed up here. And the feedback loop was then very, very short and tight. And so a lot of things got developed fairly quickly that”
2020-07-18 · Lex Fridman Podcast · #109 – Brian Kernighan: UNIX, C, AWK, AMPL, and Go Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“Where it was really easy to write programs. It could be highly productive. And part of that was to be a community. And there's some observation from Dennis Ritchie, I think at the end of the book that says that from his standpoint, the real goal was to create a community where people could work as programmers on a system. And I think in that sense, certainly for many, many years, it's succeeded quite well at that. And part of that is the technical aspects of because it made it really easy to write programs, people did write interesting programs. Those programs tended to be used by other programmers. And so it was kind of a virtuous circle of more and more stuff coming out that was really good for programmers.”
2020-07-18 · Lex Fridman Podcast · #109 – Brian Kernighan: UNIX, C, AWK, AMPL, and Go Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“I think one aspect to fundamental philosophy was to provide an environment that made it easy to write or easier, productive to write programs. So it was meant as a programmer environment. It wasn't meant specifically as something to do some other kind of job. For example, it was used extensively for word processing, but it wasn't designed as a word process.”
2020-07-18 · Lex Fridman Podcast · #109 – Brian Kernighan: UNIX, C, AWK, AMPL, and Go Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“In certain kinds of ways. In some ways, yeah, absolutely. I think most people didn't take too kindly to the bureaucracy, and I'm sure the bureaucracy put up with an enormous amount that they didn't really want to.”
2020-07-18 · Lex Fridman Podcast · #109 – Brian Kernighan: UNIX, C, AWK, AMPL, and Go Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“Oh, there's a lot of them in a sense. And again, it's a question of can you resurrect them in real time if his memory fails. But I think part of it was that Bell Labs at the time was a very special kind of place to work because there were a lot of interesting people and the environment was very, very open and free. It was a very cooperative environment, very friendly environment. And so if you had an interesting problem, you go and talk to somebody and they might help you with the solution. And it was kind of a fun environment too in which people did strange things and often tweaking the bureaucracy in one way or another.”
2020-07-18 · Lex Fridman Podcast · #109 – Brian Kernighan: UNIX, C, AWK, AMPL, and Go Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“It's quite surprising. And you asked earlier about prediction. The answer is no. There's no way you could predict that kind of evolution. And I don't know whether it was inevitable or just a whole sequence of blind luck, I suspect, more of the latter. And so I look at it and think, gee, that's kind of neat. I think the real question is, what does Ken think about that? Because he's the guy arguably from whom it really came, you know, tremendous contributions from Dennis Ritchie and then others around in that Bell Labs environment. But if you had to pick a single person, that would be Ken.”
2020-07-18 · Lex Fridman Podcast · #109 – Brian Kernighan: UNIX, C, AWK, AMPL, and Go Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“Well, there could be debuggers, but that's the same problem, right? How do you actually get something that will help you debug it? So part of it is an ability to see the big picture. Now, these systems were not big in the sense that today's pictures are, so the big picture was in some sense more manageable. I mean, then realistically, there's an enormous variation in the capabilities of programmers. And Ken Thompson, who did that first one, is kind of the singularity in my experience of programmers with no disrespect to you or even to me. Several leagues removed. I know”
2020-07-18 · Lex Fridman Podcast · #109 – Brian Kernighan: UNIX, C, AWK, AMPL, and Go Programming · IDENTIFIED FROM THE TRANSCRIPT · source