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).
I checked out that youtube link too - you might be interested to know that his t-shirt says "επιτέλους το κατάλαβα" which is Greek for "eventually I understood it" - I thought that was neat :)
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.
I remember that when a friend first introduced me to Linux around 2002 (we were both high school kids), I ended up writing a rudimentary printer driver as the printing support in Linux required installing 250MB worth of packages that I simply didn't have enough space for, as I had installed Linux to a 1GB partition that I got after squeezing the Win98 on my father's laptop into 3GB. I used Red Hat Linux—not the most minimal distro but I had no idea what I was doing. So when I wanted to print something and couldn't install the printing packages, I grabbed the paperback printer manual which described all the low-level commands the printer supported, studied it to find the commands I'd need and then wrote a simple program that took an image and sent it to the printer. It couldn't have been longer than a few hundred lines.
The printers back then were simple and came with real reference manuals that documented how to communicate with the printer, so you could really write a simple printing program/driver without being a UNIX legend (I am not).
Unix founder number
Bell Labs number
Preventing the Collapse of Civilization / Jonathan Blow (Thekla, Inc)
> 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 . “We can not solve our problems with the same level of thinking that created them”, as Lincoln said. ;)
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!
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!
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. :)
I also think there are many straight interview podcasts and I'm trying to do something different.
For example, Accidental Tech Podcast inserts a small jingle at the start of a sponsor break whereas Talk Python inserts a sudden awkward silence in the conversation. It took me many episodes of the latter to stop wondering if the player had crashed, or if the interviewer lost his train of thought, or the guest was offended, etc. The jingle lets the listener know what's happening, which gives a more relaxing listing experience.
So some easy way to distinguish the interview from the narration would be useful, I think.
But maybe I'll be less confused once I've listened to a few more episodes. A new podcast always takes some getting used to. Thanks for making 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?
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.
I’ll for sure be including a link to it in one of my upcoming newsletters.
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.