11 ms·

Thanks for submitting this. I did the interview. I think you have to listen to it to get the full experience. But here are some things that were interesting a

by agbell 6y ago

Thanks for submitting this. I did the interview. I think you have to listen to it to get the full experience. But here are some things that were interesting and surprising from the interview: The UNIX room - The unix room at bell labs was a shared room where they would hang out and have coffee. Some people worked exclusively in the UNIX room, like Ken Thompson, but most worked in their private offices and came to the UNIX room to share what they worked on and have a coffee and catch up. This room was the culture center of the computing group at Bell Labs. Because they were all sharing a file system on a single machine, it was easy for various people to iterate on programs. They only had one rule which was if you changed the program last, you were the owner. In some ways, it mirrors how open source works today. Brian is super modest and claims to be a horrible programmer but he is comparing himself to Ken Thompson, who he thinks is just incredible. Ken once wrote a disassembler, assembler and B interpreter for a mini-computer that ran a printer they were struggling with, in a couple of days, so that they could get it printing again. This blew Brian's mind. At the time, Brian didn't think that the work they were doing was 'important' in a big sense. The culture was more like working with computers is hard, let's try to make it better and lets try to solve practical problems. The book "Unix: A History and a Memoir" has many other great details.

bronson 6y ago
I love Brian Kernighan interviews so I was eager to listen. I have mixed feelings. You would often make a point and then play snippets from him supporting it. You often gave yourself center stage and used him as evidence. I found it overedited and synthetic, more a performance than an interview. I came for BWK and left unsatisfied. If that's the style you were going for, that's fine. Maybe it's just my expectations. It was entertaining lisen. Thank you for making it!
- agbell 6y ago
  Oh, I'm sorry you didn't like the format. Thanks for giving it a listen anyhow.
  - deleted 6y ago
    [deleted]
  - peterburkimsher 6y ago
    I think the format is good for your podcast, where your listeners would be used to hearing your voice. On Hacker News though, people are a bit more familiar with BWK. Thank you very much for transcribing the text; it's better to listen, but it's easier to translate to other languages, and also read while looking busy in an office. The audio is better for the Canadian accents though!
  - ptx 6y ago
    I suppose this is just matter of personal preference, but I'm not a big fan of this style of podcast either - although I did greatly enjoy the episode! I just felt it would have been even better if it were simply a conversation, without jumping back and forth in time, inserting explanations (although they were helpful), etc. As you said in the podcast - "start at the beginning". If it had then proceeded from the beginning to the middle and from there to the end, I would have found it more relaxing to listen to. On the other hand, there are some of these heavily edited, radio-style podcasts that lots of people think are amazing but leave me confused and annoyed. So maybe you shouldn't listen to me. :)
    - agbell 6y ago
      That makes sense. Part of my process is having people listen through to the interview and let me know where they get confused. Then I add in explanations there. The explanations mean people don't get lost if they don't know what punch cards are or fortan for instance. I also think there are many straight interview podcasts and I'm trying to do something different.
      - mutagen 6y ago
        I think your podcast and format is great, keep doing it and refining it. I look forward to listening to each new episode because of the interesting and wide ranging guests and the broader viewpoint you look for in the discussions.
- duderoso 6y ago
  i bet you give great code reviews
- swyx 6y ago
  there are people who feel strongly the opposite way - this format offers more context, cuts out small talk, allows the narrator to construct a story. to each their own... perhaps the OP could release the raw audio if they wished to cater to both
dwcnnnghm 6y ago
> Brian is super modest and claims to be a horrible programmer but he is comparing himself to Ken Thompson, who he thinks is just incredible. Ken once wrote a disassembler, assembler and B interpreter for a mini-computer that ran a printer they were struggling with, in a couple of days, so that they could get it printing again. This blew Brian's mind. For the next level up here's Ken (in a very interesting conversation with Brian Kernighan about the history of Unix) describing McIlroy: > McIlroy keeps coming up. He's the smartest of all of us and the least remembered (or written down)... McIlroy sat there and wrote ---on a piece of paper, now, not on a computer--- TMG [a proprietary yacc-like program] written in TMG... And then! He now has TMG written in TMG, he decided to give his piece of paper to his piece of paper and write down what came out (the code). Which he did. And then he came over to my editor and he typed in his code, assembled it, and (I won't say without error, but with so few errors you'd be astonished) he came up with a TMG compiler, on the PDP-7, written in TMG. And it's the most basic, bare, impressive self-compilation I've ever seen in my life. This story, by the way, leads into how Ken created B (and how that was eventually improved by Dennis Ritchie into C). [0] https://youtu.be/EY6q5dv_B-o?t=2314 https://youtu.be/EY6q5dv_B-o?t=2314
- agbell 6y ago
  Thats a terrific story! Another interesting thing is that they were often working on very practical problems, grounded to the real world. The second unix system, the PDP 11 machine was being used for patent applications, so they had to build text processing tools and also be very careful not to break anything that the patent clerks needed. I think this combination was the key, smart people and practical problems.
  - vram22 6y ago
    Yes. What I read somewhere is that the early Unix team (some of whom had just come off the Multics project) got the full use of a spare minicomputer that was in the Labs, to build an early protototype of Unix (may or not be the first one), only by promising their manager that they would build text processing software on top of it that would be useful for the Labs' patent and other text processing work. And they delivered. Some of that work became a software suite called Writer's Workbench, IIRC, and some of it became the powerful Unix command line filters and such that we still love and use today, such as cut, paste, join, diff, tr and more - "more" as in "etc.", not the pager tool, although maybe that one too, ha ha.
agbell 6y ago
If you have any future topic or guest suggestions let me know.
AugieDB 6y ago
I loved this episode when I first heard it, but reading your recap of it reminds me of a similar story from my college days. I had a CompSci professor who had worked at Bell Labs, which was all of 10 minutes down the street from the college. I remember he was having problems with printing something in the computer lab one week, so he wrote a driver for the printer over the weekend. This would have been about 1997 or so. And he talked about it like it was nothing, the simplest thing in the world. It looks like my professor was just taking after the people he worked with. For that level of programmer, writing new drivers for hardware was a weekend project. One of our CompSci textbooks was written by that same professor -- I just took it down off the shelf and looked at the intro. Brian K. was thanked for being an early reader of "several revisions." In retrospect, it's really cool to have been only a couple degrees away from that kind of history -- and I probably didn't quite realize how awesome that was back then.
- agbell 6y ago
  Thats a great story! thanks for sharing
- ssivark 6y ago
  That’s fascinating. How is it that we seem to have lost that capability to do things in software over so few decades?
  - wolfgke 6y ago
    There is a talk by Jonathan Blow about this topic: Preventing the Collapse of Civilization / Jonathan Blow (Thekla, Inc) https://www.youtube.com/watch?v=ZSRHeXYDLko https://www.youtube.com/watch?v=ZSRHeXYDLko
    - leoc 6y ago
      A lot of what Blow says is not entirely accurate. For example he presents a simple picture of declining software quality over time, but anyone who was around at the time knows that both desktop OSes and desktop applications (including web browsers) were certainly much more crashy, and probably more buggy in general, than they are now. Likely quality has started to decline again over the past decade, but it's still not remotely back to where it was. It's hard not to suspect that Blow passes over this because it tends to contradict his "higher-level languages and more infrastructure → declining quality" argument. Section 7.4, "Programming Environments Matter" http://philip.greenspun.com/research/tr1408/lessons-learned.html http://philip.greenspun.com/research/tr1408/lessons-learned.... of Phil Greenspun's, apparently, 1993 SITE CONTROLLER dissertation https://dspace.mit.edu/handle/1721.1/7048 https://dspace.mit.edu/handle/1721.1/7048 makes the same "we don't expect software to work any more" lament which Blow delivers at 22:17 https://youtu.be/ZSRHeXYDLko?t=1337 https://youtu.be/ZSRHeXYDLko?t=1337 : > Another reason the "horde of C hackers" approach has worked remarkably well is that, although the resultant software is rife with bugs, most users have no experience with anything better. When an MBA's Macintosh Quadra crashes due to a C programmer's error in Microsoft Excel, he doesn't say "I remember back in 1978 that my VAX 11/780, with only one tenth the processing power of this machine, had memory protection between processes so that a bug in one program couldn't corrupt the operating system or other applications." Rather, he is likely to say, "Well, it is still easier than using pencil and paper." but places the blame on a switch to lower-level languages and runtime systems. The improvements on the desktop over about the '00s seem to be attributable to (not an expert) the mainstreaming of, and continued development of, the WinNT and OS X platforms, increasing use of memory-managed languages and/or more recent versions of C++ in applications, and adoption of online crash-reporting infrastructure (though probably also increasing use of increasingly effective error-detection tools, which I assume Blow is fine with as they don't create a runtime dependency). So it certainly seems that Greenspun is more correct than Blow, which is certainly not to say that adding more layers of infrastructure has always been an unqualified good. Also, Blow's talk has a very '90s focus on crashers, error messages, and the like, but many of the worst regressions in software over the last 10 or 20 years don't manifest as crashers or other straightforward bugs at all; and when they do manifest as bugs the bugginess is often intertwined with architectural issues in a way that makes a bug-hunting mentality relatively ineffective. For example, the pinnacle of WYSIWYG rich text editing was probably about Word 4 for Macintosh, which was a slightly awkward but workable mating of stylesheets to the WYSIWYG UI. Unfortunately it was something of a local optimum: further progress on the problem largely requires serious developer thought and/or further user education. So everyone more or less decided to instead pretend that rich text is a solved problem, and things have largely been gently regressing since then. Which is probably part of the deep background to the GMail rich-text jank Blow complains about at 23:47 https://youtu.be/ZSRHeXYDLko?t=1427 https://youtu.be/ZSRHeXYDLko?t=1427 . “We can not solve our problems with the same level of thinking that created them”, as Lincoln said. ;)
vim-guru 6y ago
I've been enjoying your podcasts a lot over the last couple of years. Good topics, interviews and tone. Just wanted to give you some praise for a job well done.
crispyambulance 6y ago
It was an enthralling interview, thanks so much for doing it! I've met folks who worked in Bell Labs and feel enormous envy for the opportunity they enjoyed by working there. Sadly, Bell Labs now seems like a distant, never-to-be-repeated experiment. There's so much intense focus these days on short-term ROI and responding to market pressures. Creativity and discovery very much take a back-seat to predictability and keeping the stock market "happy". Are there modern-day places like Bell Labs? Or am I idealizing what it was like there?
- vram22 6y ago
  >Are there modern-day places like Bell Labs? Don't know the answer to your exact question. But I wouldn't be surprised if there are at least a few (meaning tens, if not a few hundred) of startups / small and medium companies in the world that have at least a partly Bell Labs-like tech and innovation culture, somewhat modified due to being commercial entities vs. a research place. I have come across descriptions of actual such companies in the past.
mjgs 6y ago
Really enjoyed the interview, thanks for making it. I’ll for sure be including a link to it in one of my upcoming newsletters.
justin66 6y ago
I really appreciate that you included a transcript of the interview.

by agbell 6y ago

bronson 6y ago

I love Brian Kernighan interviews so I was eager to listen. I have mixed feelings. You would often make a point and then play snippets from him supporting it. You often gave yourself center stage and used him as evidence. I found it overedited and synthetic, more a performance than an interview. I came for BWK and left unsatisfied. If that's the style you were going for, that's fine. Maybe it's just my expectations. It was entertaining lisen. Thank you for making it!

agbell 6y ago
Oh, I'm sorry you didn't like the format. Thanks for giving it a listen anyhow.
- deleted 6y ago
  [deleted]
- peterburkimsher 6y ago
  I think the format is good for your podcast, where your listeners would be used to hearing your voice. On Hacker News though, people are a bit more familiar with BWK. Thank you very much for transcribing the text; it's better to listen, but it's easier to translate to other languages, and also read while looking busy in an office. The audio is better for the Canadian accents though!
- ptx 6y ago
  I suppose this is just matter of personal preference, but I'm not a big fan of this style of podcast either - although I did greatly enjoy the episode! I just felt it would have been even better if it were simply a conversation, without jumping back and forth in time, inserting explanations (although they were helpful), etc. As you said in the podcast - "start at the beginning". If it had then proceeded from the beginning to the middle and from there to the end, I would have found it more relaxing to listen to. On the other hand, there are some of these heavily edited, radio-style podcasts that lots of people think are amazing but leave me confused and annoyed. So maybe you shouldn't listen to me. :)
  - agbell 6y ago
    That makes sense. Part of my process is having people listen through to the interview and let me know where they get confused. Then I add in explanations there. The explanations mean people don't get lost if they don't know what punch cards are or fortan for instance. I also think there are many straight interview podcasts and I'm trying to do something different.
    - mutagen 6y ago
      I think your podcast and format is great, keep doing it and refining it. I look forward to listening to each new episode because of the interesting and wide ranging guests and the broader viewpoint you look for in the discussions.
duderoso 6y ago
i bet you give great code reviews
swyx 6y ago
there are people who feel strongly the opposite way - this format offers more context, cuts out small talk, allows the narrator to construct a story. to each their own... perhaps the OP could release the raw audio if they wished to cater to both

dwcnnnghm 6y ago

> Brian is super modest and claims to be a horrible programmer but he is comparing himself to Ken Thompson, who he thinks is just incredible. Ken once wrote a disassembler, assembler and B interpreter for a mini-computer that ran a printer they were struggling with, in a couple of days, so that they could get it printing again. This blew Brian's mind. For the next level up here's Ken (in a very interesting conversation with Brian Kernighan about the history of Unix) describing McIlroy: > McIlroy keeps coming up. He's the smartest of all of us and the least remembered (or written down)... McIlroy sat there and wrote ---on a piece of paper, now, not on a computer--- TMG [a proprietary yacc-like program] written in TMG... And then! He now has TMG written in TMG, he decided to give his piece of paper to his piece of paper and write down what came out (the code). Which he did. And then he came over to my editor and he typed in his code, assembled it, and (I won't say without error, but with so few errors you'd be astonished) he came up with a TMG compiler, on the PDP-7, written in TMG. And it's the most basic, bare, impressive self-compilation I've ever seen in my life. This story, by the way, leads into how Ken created B (and how that was eventually improved by Dennis Ritchie into C). [0] https://youtu.be/EY6q5dv_B-o?t=2314 https://youtu.be/EY6q5dv_B-o?t=2314

agbell 6y ago
Thats a terrific story! Another interesting thing is that they were often working on very practical problems, grounded to the real world. The second unix system, the PDP 11 machine was being used for patent applications, so they had to build text processing tools and also be very careful not to break anything that the patent clerks needed. I think this combination was the key, smart people and practical problems.
- vram22 6y ago
  Yes. What I read somewhere is that the early Unix team (some of whom had just come off the Multics project) got the full use of a spare minicomputer that was in the Labs, to build an early protototype of Unix (may or not be the first one), only by promising their manager that they would build text processing software on top of it that would be useful for the Labs' patent and other text processing work. And they delivered. Some of that work became a software suite called Writer's Workbench, IIRC, and some of it became the powerful Unix command line filters and such that we still love and use today, such as cut, paste, join, diff, tr and more - "more" as in "etc.", not the pager tool, although maybe that one too, ha ha.

agbell 6y ago

If you have any future topic or guest suggestions let me know.

AugieDB 6y ago

I loved this episode when I first heard it, but reading your recap of it reminds me of a similar story from my college days. I had a CompSci professor who had worked at Bell Labs, which was all of 10 minutes down the street from the college. I remember he was having problems with printing something in the computer lab one week, so he wrote a driver for the printer over the weekend. This would have been about 1997 or so. And he talked about it like it was nothing, the simplest thing in the world. It looks like my professor was just taking after the people he worked with. For that level of programmer, writing new drivers for hardware was a weekend project. One of our CompSci textbooks was written by that same professor -- I just took it down off the shelf and looked at the intro. Brian K. was thanked for being an early reader of "several revisions." In retrospect, it's really cool to have been only a couple degrees away from that kind of history -- and I probably didn't quite realize how awesome that was back then.

agbell 6y ago
Thats a great story! thanks for sharing
ssivark 6y ago
That’s fascinating. How is it that we seem to have lost that capability to do things in software over so few decades?
- wolfgke 6y ago
  There is a talk by Jonathan Blow about this topic: Preventing the Collapse of Civilization / Jonathan Blow (Thekla, Inc) https://www.youtube.com/watch?v=ZSRHeXYDLko https://www.youtube.com/watch?v=ZSRHeXYDLko
  - leoc 6y ago
    A lot of what Blow says is not entirely accurate. For example he presents a simple picture of declining software quality over time, but anyone who was around at the time knows that both desktop OSes and desktop applications (including web browsers) were certainly much more crashy, and probably more buggy in general, than they are now. Likely quality has started to decline again over the past decade, but it's still not remotely back to where it was. It's hard not to suspect that Blow passes over this because it tends to contradict his "higher-level languages and more infrastructure → declining quality" argument. Section 7.4, "Programming Environments Matter" http://philip.greenspun.com/research/tr1408/lessons-learned.html http://philip.greenspun.com/research/tr1408/lessons-learned.... of Phil Greenspun's, apparently, 1993 SITE CONTROLLER dissertation https://dspace.mit.edu/handle/1721.1/7048 https://dspace.mit.edu/handle/1721.1/7048 makes the same "we don't expect software to work any more" lament which Blow delivers at 22:17 https://youtu.be/ZSRHeXYDLko?t=1337 https://youtu.be/ZSRHeXYDLko?t=1337 : > Another reason the "horde of C hackers" approach has worked remarkably well is that, although the resultant software is rife with bugs, most users have no experience with anything better. When an MBA's Macintosh Quadra crashes due to a C programmer's error in Microsoft Excel, he doesn't say "I remember back in 1978 that my VAX 11/780, with only one tenth the processing power of this machine, had memory protection between processes so that a bug in one program couldn't corrupt the operating system or other applications." Rather, he is likely to say, "Well, it is still easier than using pencil and paper." but places the blame on a switch to lower-level languages and runtime systems. The improvements on the desktop over about the '00s seem to be attributable to (not an expert) the mainstreaming of, and continued development of, the WinNT and OS X platforms, increasing use of memory-managed languages and/or more recent versions of C++ in applications, and adoption of online crash-reporting infrastructure (though probably also increasing use of increasingly effective error-detection tools, which I assume Blow is fine with as they don't create a runtime dependency). So it certainly seems that Greenspun is more correct than Blow, which is certainly not to say that adding more layers of infrastructure has always been an unqualified good. Also, Blow's talk has a very '90s focus on crashers, error messages, and the like, but many of the worst regressions in software over the last 10 or 20 years don't manifest as crashers or other straightforward bugs at all; and when they do manifest as bugs the bugginess is often intertwined with architectural issues in a way that makes a bug-hunting mentality relatively ineffective. For example, the pinnacle of WYSIWYG rich text editing was probably about Word 4 for Macintosh, which was a slightly awkward but workable mating of stylesheets to the WYSIWYG UI. Unfortunately it was something of a local optimum: further progress on the problem largely requires serious developer thought and/or further user education. So everyone more or less decided to instead pretend that rich text is a solved problem, and things have largely been gently regressing since then. Which is probably part of the deep background to the GMail rich-text jank Blow complains about at 23:47 https://youtu.be/ZSRHeXYDLko?t=1427 https://youtu.be/ZSRHeXYDLko?t=1427 . “We can not solve our problems with the same level of thinking that created them”, as Lincoln said. ;)

vim-guru 6y ago

I've been enjoying your podcasts a lot over the last couple of years. Good topics, interviews and tone. Just wanted to give you some praise for a job well done.

crispyambulance 6y ago

It was an enthralling interview, thanks so much for doing it! I've met folks who worked in Bell Labs and feel enormous envy for the opportunity they enjoyed by working there. Sadly, Bell Labs now seems like a distant, never-to-be-repeated experiment. There's so much intense focus these days on short-term ROI and responding to market pressures. Creativity and discovery very much take a back-seat to predictability and keeping the stock market "happy". Are there modern-day places like Bell Labs? Or am I idealizing what it was like there?

vram22 6y ago
>Are there modern-day places like Bell Labs? Don't know the answer to your exact question. But I wouldn't be surprised if there are at least a few (meaning tens, if not a few hundred) of startups / small and medium companies in the world that have at least a partly Bell Labs-like tech and innovation culture, somewhat modified due to being commercial entities vs. a research place. I have come across descriptions of actual such companies in the past.

mjgs 6y ago

Really enjoyed the interview, thanks for making it. I’ll for sure be including a link to it in one of my upcoming newsletters.

justin66 6y ago

I really appreciate that you included a transcript of the interview.