CoRecursive: Coding Stories - Chat: 2020 Year End

Episode Date: January 1, 2021

Welcome to the year-end episode. Today is all the bonus questions. Often times I have questions that I want to ask guests, but they don't quite fit the overall theme of the episode. So today we're going to do a whole episode of those extra questions. I have previously recorded questions for Brian Kernaghan, the creator of AWK among many other things. I have questions for Sean Allen, who works at Microsoft Research, and a couple of other people. Episode Page: http://corecursive.com/060-2020-year-end Slack Channel: https://rebrand.ly/corec_slack Twitter: https://twitter.com/adamgordonbell  

Hello and welcome to Co-Recursive, the stories behind the code. I'm Adam Gordon-Bell, the host. Welcome to the year-end episode. Today is all bonus questions. Oftentimes, I have questions I want to ask guests, but they don't quite fit the overall theme of the episode. So today, we're going to do a whole episode of those extra questions. I have questions for Ryan Kernaghan, the creator of Ock, among many other things.

I have questions for Sean Allen, who works at Microsoft Research, and a couple of other people. We're going to start with Jim Blandy. Jim Blandy was the guest on episode 54. One thing you might not know about Jim is he's been working on open source software for his entire career. I think that's pretty cool. It means that all the code that he's written is out there somewhere in the world.

You know, it's visible. It's not locked up in proprietary software. It's visible. It's not locked up in proprietary software. It's kind of like Jim's personal career portfolio. So I asked Jim what happened and it turned out he started working on the Emacs project as soon as he finished university. The story behind it is super interesting. So basically what happened is I had been working for Project GNU on Emacs as the Emacs maintainer for several years. And Richard Stallman was my boss and I was working remotely from Ohio. And Stallman had been really very helpful to me. I had some difficulties learning to work remotely. I was just out of

college. And he really, in his own difficult way, he was actually very supportive and helped me get into the pattern. But after I'd done that for two years, I quit. And it was funny. I had just finished a project sort of looking, doing a survey of the copyrights on all of the Emacs Lisp modules that are distributed with Emacs and making sure that everything was on the up and up. And so I called him up one night and said, okay, Richard, I finished the copyright survey. And he says, oh, good. And I said, and I'm going to quit. And he said, oh, no. And then he hangs up the phone on me. And that was our last conversation as an employee. Jim quit the Emacs job so that he could do a bit of world traveling. But when he got back, he had to find a new job.

My friend Carl Fogel had gotten a job working at the University of Illinois, Urbana-Champaign, on a gene editing mode for Emacs. And this is in Emacs, you visit a file that's full of genetic data. And Emacs will bring it up and it'll apply colors to it. And you can like select, you know, rectangles and stuff like that. And so basically this, the lab that my friend was working for, their big triumph was that they were able to build trees that had like hundreds of organisms in them. Right. And like nobody else had ever been able to, people had said, oh yeah, that, that technique is too difficult. You'd never do it. Basically, they took every kind of organism you could find. It turns out that since all cellular life synthesizes proteins from their genes, you have a genetic sequence that describes a protein, you've got to make the protein. That's done by an enzyme called a ribosome. And everybody's got ribosomes.

Bacteria have ribosomes. Humans have ribosomes. Oak trees have ribosomes. You know, weird things that you find living in hot springs and at the bottom of the ocean next to volcanic vents. Everybody's got ribosomes. And so if you use the ribosome sequence as your point of comparison, you can actually compare all of life, any kind of life, all of, you know, anywhere you find it, everybody's got ribosomes, except like viruses. Viruses use somebody else's ribosomes. So, but they, they talked about how they figured out how everybody in the U S got infected from somebody in, in, uh, New York or from people from New York

that was using the same kind of analysis. It's differential analysis of the sequences. So, yeah. And, and so, so basically what they did, their, their output was they put on a t-shirt. It was such a, it was this great thing. It was this circular plot of basically every kind of life that there was, right? And it really showed the literal distances between these different kinds of organisms. And it was really funny because it had this whole big, you know, it was like a hundred organisms arranged around the circumference of the circle with the common ancestor at the center. And then things branch out from the center out towards the edge of the circle. And basically, almost all of these organisms were bacteria or single-celled organisms. And then off in one little corner of the circle, there was human beings, corn, oak trees, and yeast. They're all so close. They're so similar. If you see them walking down the street, you can't tell the difference between one and the other. They're basically all the same. Human beings, corn, oak trees, and yeast, identical. No distinction between them at all.

The project really gave you a sense of perspective. It's like, it's not really about us. We like us and we should take good care of us, but it's not about us. We like us and we should take good care of us, but it's not about us. It's not about us. Interesting thought. I'm not really sure what the takeaways are from Jim's story, but now I know there really is an Emacs mode for everything, including gene editing. In episode 58, I interviewed Brian Kernaghan, who coined the term Unix and is the K in K&R, the famous C book. In the interview, we focused a lot on how Unix was created in the early days at Bell Labs. But in this clip, I asked him about the success of Unix. Why did it end up becoming so popular?

Some of it was right place at the right time. Unix came along at a time when computers started to become affordable, not for individuals yet, but for smallish groups. So if you and half a dozen people like you working at a company, let's say, or maybe a handful of people at a university department or something, they could afford a computer. We talked earlier about 50,000 bucks. So call it something like that. That's not pocket change for either of us individually, but if we get a small group of us together, we can actually do that. And so the hardware itself was feasible, manageable for smallish

groups. And small groups have more control over their destiny than perhaps a giant group. And so in that sense, useful. And then the other thing is that the service that Unix provided, the computing environment it provided at the time was just so much better than what you would get from the operating systems and software provided by computer manufacturers. Because that was at a time when manufacturers like IBM or DAG or HP or whatever made their own operating systems. That was part of the service. They built a computer, but they also provided an operating system. And the operating system probably was even free as part of the purchase price. I don't know. And those operating systems tended to be, roughly speaking, pretty awful.

They weren't very nice to use. And you could imagine why, because it wasn't the fundamental focus of the company that was making the computer. The focus of the hardware and the software was just something that you had to provide. And so Unix provided quite a decent alternative to that. In. And so there was this kind of a wave of people following Unix onto more and more powerful machines. So the PB11 was kind of powerful for its time, but limited. But then the next generation, the VAX, which went from a 16-bit architecture to a 32-bit architecture, and that opened up a lot more possibilities. And so that was the dominant machine for a long time. I think another thing that worked was the portability of operating system and supporting code that was written in high-level language,

so that it meant that you could write something once and it would run on lots of different things. And so Unix, just as a software system, made it possible for smallish companies like Sun Microsystems in particular to design hardware. And then they didn't have to write software. They could just use Unix. And so that meant that you had hardware companies like Sun and Apollo and scattered others who were making workstation type computers and using Unix as the standard operating system. And so roughly speaking, you didn't have to do anything. If you had a bright idea for a new hardware system, you could get it off the ground, provide Unix. You might have to write some kind of compiler, but that was fundamentally it and you were up and running. And so all of

these things help spread the system. And obviously this is combined, the system itself, but combined with the hardware getting better, our understanding of software getting better, our ability to port things from one place to another getting better. So all of these things compound, if you like, to make it easy for this particular system to spread. And the other thing that happened probably in the, call it the 80s, was the development of networking, and particularly the internet, which although the internet wasn you know widespread or commercial or anything it was absolutely there for uh universities and industrial research operations like bell labs ibm xerox park and so on and so

the networking again made it possible for people to do interesting things and the networking fairly quickly converged on uh unix it was just the easiest way to do networking as well. And then I guess – Is this because Bell was like just very permissive in terms of like licensing it out to these universities and stuff? In a weird way, yes. with AT&T being this regulated public monopoly was that they weren't allowed to make money off stuff that wasn't their fundamental telephone business. Because that would be cross-subsidizing and that would be bad. What they did, and I don't know whether this was conscious or just kind of nobody was awake,

but what they did was to license Unix for academic use for practically free. It was just kind of a nuisance fee. And they licensed it for commercial use for not too expensive, $20,000, $30,000 kind of thing, because they couldn't sell it at a profit. So they had to basically just kind of say, okay, here it is, Nuisance fee, media fee, something like that. And the license for universities and commercial was very permissive. You got the source code. So you could do anything you want with it. The only thing you couldn't do was of course, distribute that code to anybody else, unless they were a Unix licensee. And so if I had a Unix license and you had one, I could show you all the stuff I did and vice versa. And so we would have, you know, in effect swap meets that very quickly became using Unix user groups. And so the community spread like that very quickly. And I think AT&T didn't even know kind of what to make of this. And they tried sporadically to make money from this with not a huge amount of success, although some.

But the licensing was also, I don't know what the right word is, but there were issues. And what happened, particularly at Berkeley, is that they decided they would start rewriting the AT&T code. So it wasn't AT&T code anymore. And that way they would be able to distribute it on their terms, which was fundamentally academic free. Here you are. And there were certainly legal fights that went on into the early 90s about, you know, what are the properties of code that was rewritten at Berkeley? And does it violate AT&T's intellectual property rights and license terms and all the rest of this stuff?

And it was probably helped along by things like Linux. I mean, it was 1991 that Torvalds created his version of Lookalike, and that was based in metaphorically, not literally, I think, on Minix, which Andy Tannenbaum had done at the Free University in Amsterdam. And it's obviously at this point, when you say Unix, and for many, many things, it actually is Linux. I feel like there could be a whole episode or many episodes about the spread of Unix and the eventual rise of Linux. Super interesting topic. Another thing that came up when talking to Brian was communicating and writing. In this clip from our first interview, I asked Brian if writing and documenting and communicating ideas was part of the reason why he had such a large

impact. Yeah, I think that's actually highly relevant in some sense. I mean, as a programmer, I'm at best average, I think, certainly not even remotely in the same league as somebody like Ken or lots of others who I've known. But I probably write better than above average in that. And so in a sense, that's an ecological niche for me that I can do something. And again, it's an example of, gee, I find this thing and it's not very well explained, or there's no explanation of it at all, or how the heck do you do this? And so let me try to figure it out well enough that I understand it myself, and then in some way, write that down so that other people can understand it better as well. Sort of an impedance matcher between the people who wrote this stuff,

and they're not interested in describing it very much, and the people who have to use it or want to be able to use it more effectively. And so I think writing in that sense has for me personally been a good thing and a chance to do something where I can compete in a way that I couldn't compete if it was just writing raw code or something like that. The other thing, and I think this is one of the things that probably Hamming said as well, when you do stuff, it's important to be able to talk about it to people who are not experts in your field. Can you explain what it is you're doing or what's going on in your field or what's important or all these kinds of things? Can you explain that to people who are not specialists in it in a way that they get the essence of the idea, um, and as a result are better educated

or informed or whatever. And so I think that's a useful thing. And I think everybody should be able to do that. Even if you're a programmer deep in the internals of something or other, you should be able to explain to someone else what it is you're doing, where it fits in, why it's important. And it's helpful to be able to both write that way and also talk that way. Be able to stand up in front of an audience, literally or metaphorically, and explain it as well. And I think that's another example of a place where if you do more of it, you get better at it, perhaps. So there's a compounding effect. Writing and communicating is important. And that's something I've been thinking about a lot

since talking to Brian. I mean, he was impactful both as a developer and as a writer. And I'm not sure how you could measure one against the other. But a lot of people I looked up to over the years, they were actually people I just knew primarily through their writing or through their speaking. If the guests on this podcast had never written things or given conference talks, I would have never knew they existed. So I would encourage you in the coming year to do some communicating, to do some writing about technology. I mean, don't feel obligated to, but if you have written something or created a YouTube video or whatever, share it on Twitter, join our Slack channel and share it there. Maybe we can help spread the word. And also, I just love to see what you're making.

Sean Allen was my guest for episode 55 and an interesting discussion we had that didn't get included in the interview concerned security around open source projects. If you haven't heard of the left pad incident, that's when a 10 line JavaScript library that padded numbers was removed from NPM and major projects like React stopped working until it was addressed. There's been a number of incidents like that, some involving Bitcoin miners as well. Sean has this interesting idea for using type systems to address this problem. Here's the clip. Almost every program is probably pretty awful on the security front right now. Yeah.

I'm kind of obsessed with open source supply chain attacks, right? Like the JavaScript thing I brought up earlier. There was some Ruby one, like the number one thing that seems to get noticed is people trying to steal stuff from people's Bitcoin wallets or whatever. But if you have a programming language where you have ambient authority, which is that basically that anything within the program

is completely trusting and can do anything it wants to. But if you take ambient authority and you combine it together with a module package system where you're trusting stuff that comes down off the internet, this is a security nightmare. I don't think it's possible with how the JavaScript community works to write a secure application based on how that system works. Any one of those modules that you pull down can do absolutely anything it wants to, right? And they have so many modules, so many dependencies that get pulled in. It's completely impossible to actually

reasonably vet them as a human being to know that it's not going to be doing something nasty to you, right? And so you go to, and then like, oh, hey, here's a security update for module foo, right? It's potentially going to pull in 30 other things for changes. And another thing, and you have hundreds of things that come in. There's no way that you can really vet that other than somebody told me that there's a security error and I need to bump this number in my lock file and then pull everything down and get 50,000 other things. This is not like my going like, oh no, JavaScript bad. It's using a model that for the most part, at least for how old I am, I would equate

back to like Pearl and CPAN. Ruby gems is the same basic thing. MPMs, the same basic thing. They're all the same model. And the programming language like, is like still built for like trusting effectively, like you're granting complete trust to this code, right? And you can't go back and retrofit this onto JavaScript. But like what could solve it? Certainly you probably need a type system of some type that will allow you to represent within the type system what activities something is allowed to do,

what it's not allowed to do, right? Yeah. Like in object capabilities languages, like where Pony has that like where pony has that there was e that mark miller did is you provide a unforgeable token is the idea right so that like here's a token that allows you to listen on a tcp socket right and uh any module that you do cannot open a tcp socket without having this authorization. This is how object capability solves it. The issue that comes from that then is people come in and they're used to working

in languages that give them ambient authority, right? And what this leads to then in general is you have a token at the top level of your program, like the top level of your program usually has ambient authority. It can do anything. And then it can turn that, it can segment off bits so that it's like, oh, okay, I can create the ability to open a TCP socket because I have ambient authority. And I'm only going to give you the ability to open a TCP socket. And then you can hand that off to anything else as well, right? You're able to do that. But this means that, for example, at the call site, I have to explicitly pass this thing along.

And now if I want to allow you to do other things in the future, this is dependency injection. Dependency injection. Not in the spring way, but the actual dependency injection of you pass your dependencies in. There is no global thing that you can go off to to talk to the database or whatever and people really dislike this from a developer like experience standpoint because it's not what they're used to and they want to just be able to go no i want to be able to do that right like what do you mean i have to pass in the ability to print the standard out? Well, yes, you have to pass in the ability to print the standard out. There's no way to do

it otherwise. And this is great for security, but it's bad for ergonomics. And I think if you look at any language like JavaScript or Go, which has has ambient authority i think that you can say on some level the security of at least a certain kind for in terms of supply chain or whatever is definitely lower than a lot of other things in their values and and that's not to say that that's that's bad or wrong but it's a choice that they make. I personally, I love open source software for whatever that means and everything. I'm just deathly worried about the ecosystem that these ecosystems were building up that they're so vibrant, we can't trust them at all. It's an interesting observation, right? Why do I have to give a function call in a library I

pulled from the internet, full authority to do everything that I can do in my code. Stated that way, it does seem like an area that needs improvement. A question that comes up in the Slack channel from time to time concerns doing computer science research or doing graduate degrees. I suppose that shouldn't be surprising considering that we sometimes drift into more academic computer science topics. In episode 52, I interviewed Crystal Mon, who's a PhD candidate. I was going to ask you about grad school, like who should consider going? I think if you're one of those persons who is looking for mentorship in a real way, and you found that maybe software engineering, you just can't find that, like you're just kind of, you're doing the thing and you feel like yeah i'm

i can create a database i can do this but like i need to know this but nobody everybody's just telling me that it doesn't matter you know like a lot of software is just very like oh just get it done and i really struggle with this because i want to understand a lot of things bit by bit so if you're one of those persons who need to kind of take things apart and really understand them, I think you'd be a really good fit. I also think that if you're a bit of a troublemaker, you'd be a really good fit for grad school. William Byrd, he's a professor at the University of Alabama. But he told me that, you know, people who are kind of the troublemakers in undergrad and people say, oh, you you know like they need to get their act together he said something happens in grad school and those people shine because they're the people who

they have to know like why but why you know they kind of question things if you're one of those persons grad school might also be a really good fit and if you're one of those persons who's fearless about failing especially i would say that you'd probably be a good fit for grad school because you have to be okay with just failing and being okay with the fact that through failing and being kind of broken down in that process of failing and being built back up, you become a better person from it.

Grad school is also a really great place for you to say, you know what, I'm going to find a professor in the music department and write a paper with them or like collaborate with people from all different departments. Like I'm doing research with somebody in the econ department of my school. I met them in a machine learning class. So we're building a machine learning model that's related to an economics concept. I absolutely love that I can do that because it's also made me better in terms of understanding that problems are not just computer science problems. They're tied to other things. Like one of the

examples is bias. Bias is not just, oh, it's just data and it's a model and whatever. It's often tied to other socioeconomic concepts or issues in the larger world. And there's also balancing that with the public's or human beings' skepticism about technology. And you see this in all areas of AI right now, like the autonomous cars and issues of algorithmic bias. What's algorithmic bias? Oh, okay, cool. Yes. So algorithmic bias is kind of a concept where we think of an algorithm as fair, and we think that it's just there's no bias in it and there was a lady she's at mit media lab i believe who found that when she was doing research she's doing robotics research that the robot would not see her face but she's black and like i've experienced this too where

i would go up to a sensor in a restroom the towel dispenser, and it just won't see my hand because it just was not trained on data that looked like mine. And so there's a huge issue right now where a lot of these machine learning models are just producing horrible, unintended results. Another example is, I believe it was Amazon that found that their hiring algorithm, their hiring AI, it was unintentionally rejecting females. So if you had anything in your resume that was like woman's chess or woman in STEM, it would reject you because the algorithm had figured or predicted that you would make a worse hire if you were female based on their data. The two issues are different, but the same. Like if your machine learning is like trying to build a function that estimates somebody and they have some sort of bias, then you're just going to reproduce that, right?

That's true. Yeah. And I think historically too, there's just not, if you have a limited data set or a sparse data set and you're training based on, so you're already starting with a skewed or unbalanced data set, then of course your model is going to have some degree of bias. And so that's pretty terrible if you're going to use those kinds of systems to do things like predict whether people are criminals or whether you should let them drive a car or not. Yeah. Do you think that like there needs to be more diversity in the kind of AI field or is the issue more related to data than the people? I think it's both. I think that perspectives are important, especially in research. And I'm actually this morning, I was involved in a group that does that is doing long term research to this capacity. It's a group based on doing machine learning for social good. And my particular group is focused on education.

So here's a good example. I feel like there's so many, so many, especially in the Haskell community, programmers who would make amazing researchers. But research is, I think it's a bit unfortunate. And my advisors, they're aware of this. It's, you're sort of at a huge disadvantage if you just didn't happen to go to a school with a strong research program.

You're pipelining these people who to go to a school with a strong research program, you're pipelining these people who already go to strong research schools, who get into the best schools, or they get into any PhD program at all, then you're limiting the pool of people who could be researchers. So this is a good example too. When the first hackerspaces I ever went to, and this is not a makerspace, it's a hackerspace. It was a grungy hacker space and I love it to death. But they just didn't have a female restroom because, and their female restroom

had chemicals in it. They were just putting a bunch of chemicals because it was just dudes. And I mean, I love them to death and I spent years there, but there's a elderly woman and her son who would show up.

The first time she said, where do I use the restroom? There's no female restroom show up the first time she said where do i use the restroom there's no female restroom was the first time that i saw the group of them just scramble to try to accommodate her you know and i just thought well this is interesting you know maybe if they had thoughts about this then it you know things so many things would be different i think one of the first conferences oh it's pldi i went to to PLDI one year, which is programming lounge is design and implementation as a volunteer. And I remember one of the other volunteers next to me, she was in PhD school already. And she was shaking her head because she said that I think it was one or three out of 300

people who were speakers at the conference were women. And it's like, you can't tell me that they couldn't find, you know, it just, I mean, I'm not like overly political about that kind of stuff, but it's just, it's a little bit scary, you know, because it can go down a really bad road if you're just not considering other points of view. So yeah, if you're one of those people then yeah come to grad school so who who shouldn't go into grad school i have personal

opinions on that i think people who are first of all if you just want to make a lot of money there's no guarantee that when you come out of grad school, you certainly won't make up for the time in terms of money that you missed. Another person I would say is the R, I am very smart type person. Because you feel so stupid every single day. You're starting from ground zero and just building your yourself up building your work up and then when you get to the point where you finally understand something you move on to different projects and then you're like oh great i guess it feels stupid again um so a lot of it is has been like that for me especially working in a

interdisciplinary team you depending on the project you have people with different strengths and i spoke to so i spoke before i went to grad school too i went to google io which is like google's big conference and jeff dean was there and so people are asking you different questions and and i asked him if he had any advice and he said and I asked him specifically about finding mentorship outside of grad school and he said that if you surround yourself with people who know more than you or people who are from different fields that you'll always be learning and I really like that I like the fact that I feel like you should struggle intellectually because that's how you you grow as a person and I I think, especially in software engineering,

it can be easy to get very comfortable just being like, oh, I'm the whatever person. And I know this library really well. I know this stack really well. And you can legitimately, unless, until you get laid off, you could get very comfortable just doing the same stuff

for like 10 years of software engineering and for grad school certainly you just do not do that it's just you're just being you're just struggling all the time and then just getting afloat and then publishing and then struggling again and then just getting afloat and then so you're doing that over and over until you become comfortable with that whole idea of struggling and gaining the information and figuring things out so if you're one of those persons who finds comfort in just always being the smartest person and being um super proud of that and condescending and smug then not to say that there aren't those people in grad school because they are but uh but if you're

one of those persons it's probably not gonna go as well as you think it is i think that the last person's the checking box person like if you're one of those persons who checks boxes grad school can take longer than you think so you know you might think that oh i'm just going to get my phd and leave and i have a cousin who's i think she she's been doing her PhD for like 10 years now. So you just, you never know how it's going to go. Or you might just end up not making it all the way through, say 50% of people drop out. So you kind of have to be flexible in that way of just, I'm here for the journey and whatever, however it works out, it works out.

I'm going to give it my best shot. And if you're not one of those people, then it's going to be rough. If you're thinking about going to grad school, I recommend just talking directly to Crystal. You can find her on the Slack channel

for the podcast. If you go to corecursive.com, there is a link for Slack or you can hit her up on Twitter or email her. She has lots of helpful advice. So that was the episode. That was also 2020. I'd like to thank my feedback advisors, Jeremy Young, John Walker, Bob Tarrio,

Brandon Brown, and Robert Mason. If the episodes this year have gotten any better, then a lot of the credit goes to them. And if they've gotten worse, then that's my fault. Also, thanks to Courtney, my wife, who puts up with me spending far too much time on podcasting. And to end, here is some Jim Blandy archival footage. Ben Collins-Sussman dug this up. I guess the pronunciation of Jif versus Gif made people nervous that Subversion would be pronounced in a strange way. So they decided to make a audio file of the canonical pronunciation. And I'm going to end with that. Until next time, thank you so much for listening. Hi, I'm Jim Blandy and I pronounce subversion,

subversion. And I don't know whether it has a capital V or not, but I've never written it that way. And I don't believe in forcing one person's interpretation of the world over another. I believe that everybody should have a chance to define their own reality. No you don't! But I pronounce subversion, subversion. Hi, I'm Jim Blandy and I don't believe in the supremacy of Western culture over other cultures but I pronounce subversion, subversion. Hi, I'm Jim Blandy and I know we're all cultural relativists here but I pronounce subversion, subversion. Hi, I'm Jim Blandy and one of the things I like about free software is that anybody can do whatever they damn well please but I pronounce subversion, subversion. Subversion. Hi, I'm Jim Blandy. And one of the things I like about free software

is that anybody can do whatever they damn well please, but I pronounce subversion, subversion. Okay. One last one and then we'll shut off. Hi, I'm Jim Blandy. And I don't really understand why anybody should care how I pronounce it, but I pronounce subversion, subversion.