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

“Moment of work. Yeah, and somebody used it, and they said, gee, that's neat, those kinds of things happened quite often in that sort of golden era in the 70s when Unix was young and there was all this low-hanging fruit and interesting things to work on. And a group of people who kind of were all together in this. And if you did something, they would try it out for you. And I think that was in some sense a really, really good time.”
2020-07-18 · Lex Fridman Podcast · #109 – Brian Kernighan: UNIX, C, AWK, AMPL, and Go Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“I don't think specific moments. I think there were lots and lots and lots of good times at Bell Labs where you would build something and it worked. Jason, it worked.”
2020-07-18 · Lex Fridman Podcast · #109 – Brian Kernighan: UNIX, C, AWK, AMPL, and Go Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“It's mixed if the truth be told. I mean, I think there are some things about that that are good. I think there's the potential for people to improve their lives all over the place, and that's obviously good. And at the same time, at least in the short time, short run, you can see lots and lots of bad as people become more tribalistic or parochial in their interests and is an enormous amount more us and them. And people are using computers in all kinds of ways to mislead or misrepresent or flat out lie about what's going on. And that is affecting politics locally. And I think everywhere in the world.”
2020-07-18 · Lex Fridman Podcast · #109 – Brian Kernighan: UNIX, C, AWK, AMPL, and Go Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“I don't know that that has brought them closer together in some ways there's sociological research that says people are in fact not as close together as they used to be. I don't know where that's really true, but I can see potential downsides and kids where you think, come on, wake up and smell the coffee or whatever.”
2020-07-18 · Lex Fridman Podcast · #109 – Brian Kernighan: UNIX, C, AWK, AMPL, and Go Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“I think it depends a lot on all kinds of things. So I trade mail with my brother and sister in Canada much more often than I used to talk to them on the phone. So probably every two or three days I get something or send something to them. Whereas 20 years ago, I probably wouldn't have talked to them on the phone nearly as much. So in that sense, that's brought my brother and sister and I closer together. That's a good thing. I watch the kids on campus and they're mostly walking around with their heads down fooling with their phones to the point where I have to duck them.”
2020-07-18 · Lex Fridman Podcast · #109 – Brian Kernighan: UNIX, C, AWK, AMPL, and Go Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“Well, I think computing has changed a tremendous amount, obviously, but I think one aspect of that is the way that people interact with each other, both locally and far away. And when I was the age of those kids, making a phone call to somewhere was a big deal because it cost serious money. And this was in the 60s, right? And today people don't make phone calls, they send texts or something like that. So there's an up and down in what people do. People think nothing of having... Correspondence, regular meetings, video, whatever with friends or family or whatever in any other part of the world, and they don't think about that at all.”
2020-07-18 · Lex Fridman Podcast · #109 – Brian Kernighan: UNIX, C, AWK, AMPL, and Go Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“Yeah, right. And so in a way, I'm expecting them to make an enormous conceptual leap from their five or ten line toy assembly language thing that adds two or three numbers to, you know, something that as a browser on their phone or whatever, but it's really the same thing.”
2020-07-18 · Lex Fridman Podcast · #109 – Brian Kernighan: UNIX, C, AWK, AMPL, and Go Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“I mean, in some sense, there's no such thing as the lowest level because you can keep going down, but that's the place where I drew the line. So the idea that computers have a fairly small repertoire of very simple instructions that they can do, like add and subtract and branch and so on, as you mentioned earlier. And that you can write code at that level and it will get things done. And then you have the levels of abstraction that we get with higher level languages like Fortran or C or whatever. And that makes it easier to write the code and less dependent on particular architectures. And then we talk about a lot of the different kinds of programs that they use all the time that they don't probably realize are programs like they're running macOS on their computers or maybe Windows and they're downloading apps on their phones and all of those things are programs that are just”
2020-07-18 · Lex Fridman Podcast · #109 – Brian Kernighan: UNIX, C, AWK, AMPL, and Go Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“Oh, yeah, yeah, a very small amount. I introduced them to how machines work at a level below high-level languages. So we have a kind of a toy machine that has a very small repertoire, a dozen instructions, and they write trivial assembly language programs for that”
2020-07-18 · Lex Fridman Podcast · #109 – Brian Kernighan: UNIX, C, AWK, AMPL, and Go Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“Rarely, and does anybody in that course go on to become a real serious programmer, but at least they've got a somewhat better idea of what all this stuff is about, not just the programming, but the technology behind computers and communications.”
2020-07-18 · Lex Fridman Podcast · #109 – Brian Kernighan: UNIX, C, AWK, AMPL, and Go Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“Well, I couldn't recommend a good book. The book I wrote for the course. I think this is one of these questions should everybody know how to program? And I think the answer is probably not, but I think everybody should at least understand sort of what it is so that if you say to somebody, I'm a programmer, they have a notion of what that might be, or if you say this is a program or this was decided by a computer running a program, that they have some vague intuitive understanding and accurate understanding of what that might imply. So part of what I'm doing in this course, which is very definitely for non-technical people, I mean, typical person in it is a history or English major, try and explain how computers work, how they do their thing, what programming is, how you write a program, and how computers talk to each other and what do they do when they're talking to each other. And then I would say nobody very well.”
2020-07-18 · Lex Fridman Podcast · #109 – Brian Kernighan: UNIX, C, AWK, AMPL, and Go Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“I don't know about that. I think what will happen is continuation of What we see in some areas, at least which is that more programming will be done by programs than by people and that more will be done by sort of declarative rather than procedural mechanisms where I say, I want this to happen. You figure out how. And that is in many cases at this point domain of specialized languages for narrow domains, but You can imagine that broadening out. And so I don't have to say so much in so much detail some collection of software. Let's call it languages or programs or something we'll figure out how to do what I want to do.”
2020-07-18 · Lex Fridman Podcast · #109 – Brian Kernighan: UNIX, C, AWK, AMPL, and Go Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“Yeah, right. Won't matter to us. So I don't know. We've seen places where Moore's law has changed. For example, mentioned earlier, processors don't get faster anymore, but you use that same growth of ability to put more things in a given area to grow them horizontally instead of vertically, as it were. So you can get more and more processors or memory or whatever on the same chip. Is that going to run into a limitation? Presumably because, you know, at some point you get down to the individual atoms. And so you've got to find some way around that. Will we find some way around that? I don't know. I just said that if I say it won't, I'll be wrong. Perhaps we will.”
2020-07-18 · Lex Fridman Podcast · #109 – Brian Kernighan: UNIX, C, AWK, AMPL, and Go Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“Some combination of those I think almost all technologies over the long run are for good, but there's plenty of examples where they haven't been good, either over a long run for some people or over a short run. And computing is one of those and AI within it is going to be one of those as well. But computing broadly. Just a today example is privacy that the use of things like social media and so on means that in the commercial surveillance means that there's an enormous amount more known about us by people, other businesses, government, whatever, than perhaps one ought to feel comfortable with. So that's an example.”
2020-07-18 · Lex Fridman Podcast · #109 – Brian Kernighan: UNIX, C, AWK, AMPL, and Go Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“I don't know. It's an interesting test. At least in some vague sense objective, whether you can read anything into the conclusions is a different story.”
2020-07-18 · Lex Fridman Podcast · #109 – Brian Kernighan: UNIX, C, AWK, AMPL, and Go Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“Yeah, I mean, Turing talked about this in his paper on machine intelligence back in, geez, I know, early 50s or something like that. And he had the idea of the Turing test. And I don't know whether the Turing test is...”
2020-07-18 · Lex Fridman Podcast · #109 – Brian Kernighan: UNIX, C, AWK, AMPL, and Go Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“Yeah, that's an optimistic point of view. And if it works that way, that would be absolutely great. And what I don't know is whether it does work that way or whether the AI mechanisms or machine learning mechanisms reinforce and amplify things that have been wrong in the past. And I don't know, but I think that's a serious thing that we have to be concerned about.”
2020-07-18 · Lex Fridman Podcast · #109 – Brian Kernighan: UNIX, C, AWK, AMPL, and Go Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“Look, I think it's very interesting. I am incredibly far from an expert. Most of what I know I've learned from my students, and they're probably disappointed in how little I've learned from them. But I think it has tremendous potential for certain kinds of things. I mean, games is one where it obviously has had an effect on some of the others as well. I think there's, and this is speaking from definitely not expertise, I think there are serious problems in certain kinds of machine learning at least because what they're learning from is the data that we give them. And if the data we give them has something wrong with it, then what they learn from it is probably wrong too. And the obvious thing is some kind of bias in the data. The data has stuff in it like, I don't know, women aren't as good at men at something. That's just flat wrong. But if it's in the data because...”
2020-07-18 · Lex Fridman Podcast · #109 – Brian Kernighan: UNIX, C, AWK, AMPL, and Go Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“Well. I guess the lesson is that in the short run, it's pretty easy to be too pessimistic or maybe too optimistic, and in the long run, you probably shouldn't be too pessimistic. I'm not saying that very well. It reminds me of this remark from Arthur Clark, a science fiction author, who says, you know, when some distinguished but elderly person says that something is possible, he's probably right. And if he says it's impossible, he's almost surely wrong. But you don't know what the timescale is.”
2020-07-18 · Lex Fridman Podcast · #109 – Brian Kernighan: UNIX, C, AWK, AMPL, and Go Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“What people thought was just a few years down the pike was more than a few years down the pike. And some parts of that are more or less now sort of under control. We finally do play games like Go and Chess and so on better than people do. But there are others in machine translation is a lot better than it used to be, but that's 50 close to 60 years of progress and a lot of evolution in hardware and a tremendous amount more data upon which you can build systems that actually can learn from some of that.”
2020-07-18 · Lex Fridman Podcast · #109 – Brian Kernighan: UNIX, C, AWK, AMPL, and Go Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“I think that was one of the, well, you've heard of AI winters. This is whatever the opposite was AI Summer or something. Games like chess at they will do prove theorems in geometry. There are all kinds of examples like that where people thought, boy, we could really do those sorts of things. I read the Kool-Aid in some sense. I still have a wonderful collection of papers called Computers and Thought that was published about that era. And people were very optimistic. And then, of course, it turned out that...”
2020-07-18 · Lex Fridman Podcast · #109 – Brian Kernighan: UNIX, C, AWK, AMPL, and Go Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“I don't know. I mean, certainly in all seriousness, I just didn't have the talent for it. When I got here as a grad student at Princeton and I started to think about research at the end of my first year or something like that, I worked briefly with John Hopcroft, who was an absolutely, you know, you mentioned during award winner, et cetera, a great guy. And it became crystal clear I was not cut out for this stuff, period. Okay. And so I moved into things where I was more cut out for it. tended to be things like writing programs and then ultimately writing books.”
2020-07-18 · Lex Fridman Podcast · #109 – Brian Kernighan: UNIX, C, AWK, AMPL, and Go Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“Trying to find something that did the job, and there was nothing that you would call, let's say, a closed form or algorithmic thing that would give you a guaranteed right answer. I mean, compare graph partitioning to max flow min cut or something like that. That's the same problem except there's no constraint on the number of nodes on one side or the other of the cod. And that means it's an easy problem, at least as I understand it. Whereas the constraint that says the two have to be constrained in size makes it a hard problem.”
2020-07-18 · Lex Fridman Podcast · #109 – Brian Kernighan: UNIX, C, AWK, AMPL, and Go Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“Well, as it turns out, I worked with Shen Lin at Bell Labs on this, and we were never able to come up with anything that was guaranteed to give the right answer. We came up with heuristics that worked pretty darn well. And I peeled off some special cases for my thesis, but it was just hard. And that was just about the time that Steve Cook was showing that there were classes of problems that appeared to be really hard, of which graph partitioning was one. But this, my expertise, such as it was, totally predates that development. Oh, wow.”
2020-07-18 · Lex Fridman Podcast · #109 – Brian Kernighan: UNIX, C, AWK, AMPL, and Go Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“Oh, absolutely. Before I did this in 1968, and I worked on graph partitioning, which is this question, you've got a graph that is a nodes and edges kind of graph. And the edges have weights. And you just want to divide the nodes into two piles of equal size so that the number of edges that goes from one side to the other is as small as possible.”
2020-07-18 · Lex Fridman Podcast · #109 – Brian Kernighan: UNIX, C, AWK, AMPL, and Go Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“The answer is no, although I'm told that somebody asked Jeff Dean if that was under what conditions P would equal NP and he said either P is 0 or N is 1 or vice versa I've forgotten Jeff Dean is a lot smarter than I am.”
2020-07-18 · Lex Fridman Podcast · #109 – Brian Kernighan: UNIX, C, AWK, AMPL, and Go Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“Yeah, exactly. You're too young. Think of T-Roff as a A predecessor to the tech family of things. It's a formatter that was done at Bell Labs in this same period of the very early 70s that predates tech and things like that by five to ten years.”
2020-07-18 · Lex Fridman Podcast · #109 – Brian Kernighan: UNIX, C, AWK, AMPL, and Go Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“An excellent book. Bob Forr wrote most of it, and so it's really, really well done. He must have been a dynamite teacher.”
2020-07-18 · Lex Fridman Podcast · #109 – Brian Kernighan: UNIX, C, AWK, AMPL, and Go Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“It's not too bad because most of the solvers have some mechanism that lets them import a model in a form. It might be as simple as the matrix itself in just some representation. Or if you're doing things that are not linear programming, then there may be some mechanism that lets you provide things like functions to be called or other constraints on the model. So all AMPL does is to generate that kind of thing and then solver deals with all the hard work. And then when the solver comes back with numbers, Ample converts those back into your original form so you know how much of each thing you should be buying or making or shipping or whatever. So we did that in 84 and I haven't had a lot to do with it since except that we wrote a couple of versions of a book on it.”
2020-07-18 · Lex Fridman Podcast · #109 – Brian Kernighan: UNIX, C, AWK, AMPL, and Go Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“And so I did that fairly quickly. We wrote, it was 3,000 lines or something, so it wasn't very big, but it sort of showed the feasibility of it that you could actually do something that was easy for people to specify models and convert it into something that a solver could work with. At the same time, as you say, the model and the data are separate things. So one model would then work with all kinds of different data in the same way that lots of programs do the same thing, but with different data.”
2020-07-18 · Lex Fridman Podcast · #109 – Brian Kernighan: UNIX, C, AWK, AMPL, and Go Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“And then pass that off to a solver, which is an entirely separate thing. And so we talked about the design of the language. I don't remember any of the details of this now, but it's kind of an obvious thing. You're just writing out mathematical expressions in a Fortran-like or a. And I wrote the first version of this ample program, my first C++ program.”
2020-07-18 · Lex Fridman Podcast · #109 – Brian Kernighan: UNIX, C, AWK, AMPL, and Go Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“Which you and I would write, you know, we'd write mathematics on the board. The sum of this is greater than the sum of that kind of thing. So you need a language to write those kinds of constraints. And Bob Forrer for a long time had been interested in modeling languages, languages that made it possible to do this. There was a modeling language around called GAMS, the general algebraic modeling system, but it looked very much like Fortran. It was kind of clunky. And so Bob spent a sabbatical year at Bell Labs in 1984. And he and his office across from me. And it's always geography. And Dave Gay and I started talking about this kind of thing. And he wanted to design a language that would make it so that you could take these algebraic specifications, you know, summation signs over sets and that you would write on the board and convert them into basically this A matrix.”
2020-07-18 · Lex Fridman Podcast · #109 – Brian Kernighan: UNIX, C, AWK, AMPL, and Go Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“Linear programming is the simplest example of this. So linear programming is taught in school is that you have a big matrix, which is always called A, and you say AX is less than or equal to B. So B is a set of constraints. X is the decision variables, and A is how the decision variables are combined to set up the various constraints. So A is a matrix and X and B are vectors. And then there's an objective function, which is just a sum of a bunch of X's and some coefficients on them. And that's the thing you want to optimize. The problem is that in the real world, that matrix A is a very, very, very intricate, very large and very sparse matrix where the various components of the model are distributed among the coefficients in a way that is totally unobvious to anybody. And so what you need is some way to express the original model.”
2020-07-18 · Lex Fridman Podcast · #109 – Brian Kernighan: UNIX, C, AWK, AMPL, and Go Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“Sure. So I preface it by saying I'm absolutely not an expert on this and most of the important work in Ample comes from my two partners in crime on that, Bob Forer, who was a professor in the industrial engineering and management science department at Northwestern. And my colleague at Bell Labs, Dave Gay, who was a numerical analyst and optimization person. So the deal is linear programming. preface this by saying they would stay.”
2020-07-18 · Lex Fridman Podcast · #109 – Brian Kernighan: UNIX, C, AWK, AMPL, and Go Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“Sure. So Ample is a language for mathematical programming, technical term. Think of it as linear programming. That is setting up systems of linear equations that are some sort of system of constraints so that you have a bunch of things that have to be less than this, greater than that, whatever. And you're trying to find a set of values for some decision variables that will maximize or minimize some objective function. So it's a way of solving a particular kind of optimization problem, a very formal sort of optimization problem, but one that's exceptionally useful.”
2020-07-18 · Lex Fridman Podcast · #109 – Brian Kernighan: UNIX, C, AWK, AMPL, and Go Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“Yeah, exactly. And so I think the language is in the playground themselves are probably not going to be the mainstream, at least for some while, but the ideas that come from there are invaluable.”
2020-07-18 · Lex Fridman Podcast · #109 – Brian Kernighan: UNIX, C, AWK, AMPL, and Go Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“At the time, it didn't seem feasible, but ultimately have wound up as part of mainstream languages as well. I mean, just go back as early as recursion, Lisp, and then follow forward functions as first-class citizens and pattern-based languages. And, gee, I don't know, closures and just on and on and on. Lambdas, interesting ideas that showed up first in, let's call it broadly the functional programming community, and then find their way into mainstream languages.”
2020-07-18 · Lex Fridman Podcast · #109 – Brian Kernighan: UNIX, C, AWK, AMPL, and Go Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“I certainly don't hope it. I'm not sure that that's right because I honestly don't think there is one language that will suffice for all the programming needs of the world. Are there too many at this point? Well, arguably. But I think if you look at the distribution of how they are used, there's something called a dozen languages that probably account for 95% of all programming at this point. And that doesn't seem unreasonable. And then there's another, well, 2000 languages that are still in use that nobody uses and or at least don't use in any quantity. But I think new languages are a good idea in many respects because they're often a chance to explore an idea of how language might help. I think that's one of the positive things about functional language is, for example, they're a particularly good place where people have explored ideas that”
2020-07-18 · Lex Fridman Podcast · #109 – Brian Kernighan: UNIX, C, AWK, AMPL, and Go Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“And if you're lucky it works. And if it doesn't work, you have no recourse. There's absolutely no way you could figure out which in these thousand different packages. And I think it's worse in the NPM environment for JavaScript. I think there's less discipline, less control there.”
2020-07-18 · Lex Fridman Podcast · #109 – Brian Kernighan: UNIX, C, AWK, AMPL, and Go Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“Yeah, that's a very perceptive kind of question. One of the reasons programming was fun in the old days was that you were really building it all yourself. The number of libraries you had to deal with was quite small. Maybe it was printf or the standard library or something like that. And that is not the case today. And if you want to do something, and you mentioned Python and JavaScript, and those are the two fine examples, you have to typically download a boatload of other stuff and you have no idea what you're getting. Absolutely nothing. I've been doing some playing with machine learning over the last couple of days, and gee, something doesn't work. Well, you pip install this, okay, and down comes another gazillion.”
2020-07-18 · Lex Fridman Podcast · #109 – Brian Kernighan: UNIX, C, AWK, AMPL, and Go Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“So I don't know whether it will ever take over the world. I think not, but it's certainly an important language and worth knowing more about.”
2020-07-18 · Lex Fridman Podcast · #109 – Brian Kernighan: UNIX, C, AWK, AMPL, and Go Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“Yeah, well, I think you captured it in a lot of ways. When it first came out, JavaScript was deemed to be fairly irregular in an ugly language and certainly in the academy. If you said you were working on JavaScript, people would ridicule you. It was just not fit for academics to work on. I think a lot of that has evolved the language itself has evolved. And certainly the technology of compiling it is fantastically better than it was. And so in that sense, it's absolutely a viable solution on backends as well as the front ends. Used well, I think it's a pretty good language. I've written Modest amount of it, and I've played with JavaScript translators and things like that. I'm not a real expert, and it's hard to keep up even there with the new things that come along with it”
2020-07-18 · Lex Fridman Podcast · #109 – Brian Kernighan: UNIX, C, AWK, AMPL, and Go Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“So it took longer than it should have. Rust is a language I would like to get back to, but probably won't. I think one of the issues you have to have something you want to do. And if you don't have something that is the right combination, if I want to do it and yet I have enough disposable time, whatever to make it worth learning a new language at the same time, it's never going to happen.”
2020-07-18 · Lex Fridman Podcast · #109 – Brian Kernighan: UNIX, C, AWK, AMPL, and Go Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“Painful, but it worked, and I tried it in Rust, and it took me several days to get it working because the model of memory management was just a little unfamiliar to me. And the problem I had with Rust, and it's back to what we were just talking about, I couldn't find good consistent documentation on Rust. Now, this was several years ago, and I'm sure things have stabilized, but at the time, everything in the Rust world seemed to be changing rapidly. And so you would find what looked like a working example, and it wouldn't work with the version of the language that I had.”
2020-07-18 · Lex Fridman Podcast · #109 – Brian Kernighan: UNIX, C, AWK, AMPL, and Go Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“Yeah, and so my experience with some languages is very positive, like Lua, a scripting language I never used. And I took my little program. The program is a trivial formatter. It just takes in lines of text of varying lengths and it puts them out in lines that have no more than 60 characters on each line. So think of it as just kind of the flow process in a browser or something. So it's very short program. In Lua, I downloaded Lua and in an hour I had it working, never having written Lua in my life, just going with online documentation. I did the same thing in Scala, which you can think of as a flavor of Java, equally trivial. I did it in Haskell. It took me several weeks. But it did run like a turtle. And I did it in Fortran 90.”
2020-07-18 · Lex Fridman Podcast · #109 – Brian Kernighan: UNIX, C, AWK, AMPL, and Go Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“It's not breaking my heart, but I would love to be able to try more of these languages. The closest I've come is in a class that I often teach in the spring here. It's a programming class. And I often give, I have one sort of small example that I will write in as many languages as I possibly can. I've got it in 20-odd languages at this point. And that's, so I do a minimal experiment with a language just to say, okay, I have this trivial task, which I understand the task, and it should, it takes 15 lines in awk and not much more in a variety of other languages. So how big is it? How fast does it run? And what pain did I go through to learn how to do it? And that's a... It's like anecdota, right? It's very, very, very narrowly focused”
2020-07-18 · Lex Fridman Podcast · #109 – Brian Kernighan: UNIX, C, AWK, AMPL, and Go Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“I would guess not really. I mean, maybe it was seen, but not at the level where it was something you had to do anything about. For a long time, processors got faster. And then processors stopped getting faster because of things like power consumption and heat generation. And so what happened instead was that instead of processors getting faster, there started to be more of them. And that's where that parallel thread stuff comes in.”
2020-07-18 · Lex Fridman Podcast · #109 – Brian Kernighan: UNIX, C, AWK, AMPL, and Go Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“But Go provides a very nice model of concurrency. It's basically the communicating sequential processes that Tony Hoare set forth, geez, I don't know, 40 plus years ago. And GoRoutines are, to my mind, very natural way to talk about parallel computation. And in the few experiments I've done with them, they're easy to write, and typically it's going to work and very efficient as well. So I think that's one place where Go stands out that that model of parallel computation is very, very easy and nice to work with.”
2020-07-18 · Lex Fridman Podcast · #109 – Brian Kernighan: UNIX, C, AWK, AMPL, and Go Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“Yeah, the people. And then with this very, very useful influence from the European school in particular, the Klaus Fear influence through Robert Griesmer, who was, I guess, a second generation down student at ETH. And so that's an interesting combination of things. And so some ways Go captures the good parts of C. It looks sort of like C. It sometimes characterized as C for the 21st century. On the surface, it looks very, very much like C. But at the same time, it has some interesting data structuring capabilities. And then I think the part that I would say is particularly useful. And again, I'm not a Go expert in spite of co-authoring the book about 90% of the work was done by Alan Donovan, my co-author, who is a Go expert.”
2020-07-18 · Lex Fridman Podcast · #109 – Brian Kernighan: UNIX, C, AWK, AMPL, and Go Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“So, I think Go first comes from that same Bell Labs tradition in part, not exclusively, but two of the three creators, Ken Thompson and Rob Pike.”
2020-07-18 · Lex Fridman Podcast · #109 – Brian Kernighan: UNIX, C, AWK, AMPL, and Go Programming · IDENTIFIED FROM THE TRANSCRIPT · source