CoRecursive: Coding Stories - Tech Talk: Structure and Interpretation of Computer Programs with Hal Abelson

Episode Date: October 1, 2019

Tech Talks are in-depth technical discussions. Adam talks to Hal Abelson about the textbook he coauthored in 1984, SICP and why it is still popular and influential today. "If you pick up almost any computing book it starts out 'here are these datatypes, these operations that you do' and somewhere around 20 or 30% through the book, they show you how to define a function or a procedure. Whereas we really take the opposite approach. We say the key thing is abstraction. So we kind of start there." "The axe [the book] is grinding is that people write programs to do one particular thing. And then the price of that is that a whole lot of software engineering ends up being trying to get out of the hole you dug yourself into because you made a program that was too specific." SICP Lectures The Structure and Interpretation of Computer Programs  Hal Interview https://corecursive.com/039-hal-abelson-sicp/

At some point, we talk about conjuring the spirit of the computer. We actually got some complaints from a couple of MIT students saying, you know, these guys in this MIT course are talking about witchcraft or something. Hello, this is Adam Gordon-Bell. Join me as I learn about building software. This is Code Recursive. Today, I talked to Hal Abelson. He co-founded the Free Software Foundation, the people behind the GPL, as well as the

Creative Commons. But what I'm talking to him about today is the textbook he co-authored, The Structure and Interpretation of Computer Programs. So the book uses Scheme, and it starts with building procedures and then higher order functions and then interpreters, compilers, virtual machines. It's a super interesting book with, I think, a unique take on computer programming. It was originally written in 1985 and still seems super relevant. So we talk a little bit about that as well. Enjoy the interview. I got this email.

I printed it out and it says like, Hey Adam, I love the podcast. Have you ever thought about talking to Hal Abelson and the other authors of The Structure and Interpretation of Computer Programs? I emailed them before. They're super nice. Their book is How I Fell in Love with Programming. Great. So I'll be super nice.

So I have the book and I'm working through it. I hadn't actually read it before. This is Max before Max reached out to me, but I had certainly heard of it. So what is the structure and interpretation of computer programs about? Well, it's basic fundamental stuff about how we think about software design. That started out as a textbook for our MIT course. So MIT in the 80s, if anybody who was going to be studying either electrical engineering or computer science basically started out by taking this course.

So the theory was in either of those fields, you got a pretty deep view of software design. And it's a fairly intellectual one. One of the tremendous advantages that Jerry and Julie and I had is that we got to build on, oh gosh, 10, 15 years of research at MIT that was kind of focused around artificial intelligence. So one of the things that's in that book is we start very, very much from a symbolic computing perspective. And more so we use Scheme, which is a dialect of Lisp, which of course was the AI language then. And it was also fairly mathematical because we aimed it at MIT undergraduates. So it was kind of natural then to start off with examples that had to do with stuff in calculus or stuff in kind of mathematical programming. And that became MIT's large computer science course.

So it's kind of amazing that, you know, that course persisted pretty much as it was for, oh, gosh, 15 years. Which, you know, when you think about it, that's kind of outrageous when you think about computing and how much it's changed. But we like to think that's because the book really is about the fundamentals. So one of the things that we start with is we say this is about abstraction and modularity. And everybody says that now, but they weren't saying it then. So it was kind of a sort of a different, almost philosophical approach to how you think about programs. And the key thing, as it says right in the introduction to the book, is that we don't think of programming so much as a way to get a computer to do stuff, as a way to express ideas about how to do things. So one of the things we say in the introduction is, gosh, you know,

mathematics is about what's true, formal way to think about what's true, whereas computer programming, computer languages, or computer science are a formal way to think about how to do stuff. So that's a pretty high level, pretty philosophical view. But I think that's successful. And I still think that that's the appropriate way to think about computing. Of course, you know, even though so much has changed, I think those fundamentals are still there. And then, of course, it got a lot of influence because for the next 15 years, kind of anybody at MIT who did either computing science or electrical engineering took that course. So that's been a foundation for a lot of people who've gone on to do pretty famous things in computing.

I never thought of that perspective. So in some ways, you think it's popular just because you had very good students who learned via it? That's always true. I mean, that's the great thing about being at MIT. But it's still, it's, you know, I just am consulting at Google. And it's pretty gratifying to walk down the hall at Google and all these people stop you and they say, hey, you know, I took your course when I was.

And that's how I really learned about programming, got into computing. So I don't want to say we're totally responsible for that. Maybe it's because we got, you know, we had the tremendous good fortune to teach at MIT. But in any case, it was true and it was a nice thing to happen. Yeah, that's interesting. So I'm working through the book and I'm really enjoying it. I would say it is unique in some of its approaches. So you mentioned this approach that you have that has to do with maybe a philosophical

approach to programming. Do you think that's become more common now? Well, certainly it's the kind of thing that you can look at everything that's going on and interpret it that way. Although I don't think that a lot of people say it even now is sort of in your face as we did in the book I don't know it's sort of funny if you pick up almost any computing book you know even these days it starts out saying here are these data types and here are these operations that you do and it kind of goes through that whole litany. And somewhere, you know, around 20 or 30 percent through the book, they show you how to define a function or a procedure.

Whereas we really take the opposite approach. We say the key thing that this is about is about abstraction. And one of the key techniques of abstraction in any programming language is having procedures for things. So we kind of start there. So even if you look at most computer languages book, they kind of start from the elements. They say there are numbers and floating point and strings and booleans and whatever there are. And for one thing, we picked Scheme, which is a latent type language. So we don't talk about any of that stuff at all. And secondly, we think the really critical thing is what we call in the book means of combination and means of abstraction, of which the primary means of abstraction is defining a procedure. So yeah, I think it's more common. Everybody talks about abstraction now.

It's almost impossible to talk about computing and stuff and, hey, this is about abstraction. But I don't think people really follow through in that sense they just kind of sit there yeah I think I agree and it's interesting what you're saying a lot of computer books programming books are about the specifics so this book is in scheme I don't think that you really talk about scheme like in the book right well that was absolutely intentional because we sort of took the attitude of a scheme well you don't even have to teach it you just use it it. That's a little bit exaggerated. But even when we did the course, we did very, very little of presenting scheme. Partly is because there's almost no syntax. So if you think about what you see in a lot of computing courses, a lot of it has to do with

syntax or a scheme. You know, it's you just just sort of have parenthesized expressions and stuff. So do you think, is scheme important to the success of the book? Oh, I think so. I think that what's critical in that. So in terms of when we think about abstraction,

one really critical thing is that you've got first-class procedures, first-class objects and first-class procedures. So if we did this, gosh, you know, when did Java get Lambda?

Not until Java 8? Yeah, yeah. How long was Java around before they figured out you want to have Lambda? I mean, JavaScript, you could play this book in JavaScript, except for there's a really important piece missing, which is because Scheme has such very simple syntax, you can start building interpreters in it. Or the extreme hack we did is doing the metacircular evaluator, where you're writing an interpreter for scheme and scheme. That'd be a little hard to do in JavaScript without some

layers of syntactic processing. So I think from an educational point of view, when you think about the big ideas, first big ideas about abstraction, and a lot of people are doing that now, and about abstraction by having as many things as possible be first class objects. think JavaScript was pretty much influenced by Scheme. But the other piece that's not missing is that when you're writing a complex program, you really should take the attitude that you're designing a language. Yeah. So you call this in the book, the linguistic approach to program design. That's right. Right. So you really take the attitude that, boy, if I'm writing something complex, I need to think about what I'm doing as if I'm writing a language. Or, you know, to say that a little less ponderously, when I think about the operations I want to produce in any kind of program I'm writing, I don't want to think about only that particular problem I'm doing right then. I want to carve out a space that's broad enough that I could be doing

that particular problem and lots of variations and lots of similar ones. Do you have an example of that? Well, again, even stuff in the book, if we're doing something that's doing arithmetic, gosh, I not only want to do arithmetic on, who knows, fixed point numbers, I want to be able to have that same arithmetic idea going on floating point numbers and even on symbolic numbers. It's all the same idea because tomorrow that algebra routine I wanted to do suddenly wants to be able to work on symbols.

So if I think about, I've got to just carve out a space of not just doing one particular problem, but having enough room that I can play around or as the specs change, I can change and do something else more general or more different. Then I start thinking of what I'm doing, not as solving a particular problem or a particular algorithm, but really designing a special purpose language for something. So that's what we mean by the linguistic theory of design. But then the way that relates to scheme is you say, well, gosh, you know, the extreme version of that is we want to give students exercises in writing little languages. What's nice in those little languages is if the syntax doesn't get in the way. So as much as people

say it's awkward to be sitting there in fully parenthesized expressions and all of that, if you're actually writing the language that has to process that stuff, that makes it easier on you as the implementer. Yeah. There's an interesting example at the beginning that I was just thinking of, which is like, we try to approximate the square root of something, and then

a little bit later on, I think we use the same technique to approximate something else, and then eventually we have like, we're just approximating things. Right. You sort of basically say, you know, there's square root and that's an example of, again, it's all about abstraction. It's sort of the square root thing.

But guess what? That's an example of Newton's method. And guess what? At the next level, that could be Newton's method where one of the inputs to your procedure is the actual function you're trying to approximate, which comes in as a higher order. I think that might have been our first example of a higher order function. That's part of what I meant by language and abstraction. Right. So when I say, gee, I want to have a thing that does Newton's method, it's not just doing it for square root and not even just doing it for numerical functions.

It could be doing something very, very general. Yeah, it is crazy to think, well, from my perspective, right, if the book was written in 1985, and like you're saying, Java got lambdas in, I don't know when. Just the last couple of years. Yeah. You're definitely ahead of the curve. Is that why you chose Scheme? Are you averse to syntax in all its forms? Well, not to, what's a great quote in there from Alan Perlis? Syntax, something like the syntax leads to cancer of the semicolon or something. Nice. One of these terrific Alan Perlis quotes. So you think that syntax is?

Well, it's sometimes great. And, you know, of course, now these days you have many more interactive editors. When you start typing something and it'll fill in a syntactically correct expression, you know, that stuff wasn't around when we did it. But even so, the idea that there's really uniform syntax helps a tremendous amount in sort of getting rid of the weeds when you're trying to think about a program. You know, even so, you know, Lisp and Scheme, you know, have their glitches too. You know, even McCarthy sort of said the way they do conditional expressions conned with this double parentheses stuff.

And I think even McCarthy said that was a mistake. I mean, it seems to me that it's very important to this book. I find syntax helps with scanning. Like it's easier to read things that have a more dense syntax. Right, right. And then there are variations of Scheme, which use square brackets in some things. So you distinguish between parentheses and square brackets. And I don't know, it's a trade-off. I use standard Scheme with just parentheses myself.

Don't use any aids more than parentheses balancing. But, you know, I can see lots of people, especially those who are raised in the other extreme, especially when you have these interactive editors that fill in things. I can sort of see that role. But again, there's the other piece of it is what's it like for you as the language you're going to implement a new language? How much do you have to worry about the syntax of expressions in your implementation, right? As opposed to the real semantics of what you're trying to implement. Yeah. The language perspective is interesting. And like, you're not taking it lightly because the book actually goes through building an interpreter and then a compiler. And then there've been like real compilers that have started with what's in that book.

And then I think even a virtual machine, right? I only skimmed that far. Yeah. Right. That's when you, you know, you sort of really want to make something. It's really good that when we have students in the class, they can actually run this stuff, right? So, you know, so the virtual machine, you know, sort of goes down, sort of goes down to the bottom, to the bottom of the stack. It's interesting because I'm thinking, you said this was being taught to like electrical engineers, and I would expect that that a class would approach things the opposite manner, right? Like starting with circuits. Yeah, well, you know, in the very, very beginning days, you know, we would teach sort of short courses for MIT faculty, and some of the electrical engineers would just get stuck.

You know, you haven't showed us how the transistors work. You know, there's less of that now, but still some. And, you know, there are people who think different ways. Some people have to be grounded on where they're comfortable. And for some people, well, you know, it really is transistors. They're mapping in their head somehow the computer program down to that level. And if you haven't presented that mapping, then... Or they don't feel comfortable starting on the very high abstraction level. Whereas I think for most computer scientists these days, that's sort of how we work. Well, the stack is too big for my head, like the amount of things, right?

Yeah, well, that's what we say, right? Again, we're sort of in the world where we really think in terms of abstraction. So we're perfectly comfortable with a stack like that. And we say, gosh, we only look at a certain level and blow that well. Somebody made it working that way. So do you think that we need to learn all these levels? Should we learn C? Should we learn assembly?

Well, again, it sort of should. The question is, where do you, you know, what's it for? I mean, there's certainly places where you really, really need people who know exactly how the bits are massaged, mostly for real optimization

and getting speed. There's a real place for that stuff, too. But I wouldn't worry about that in sort of, you know, in MIT, you kind of hit that maybe in a couple of specialized courses for juniors and seniors. But I wouldn't, I certainly wouldn't start with that. But you got to remember, I don't even know if it's still true. There were these computer books,

there still are, you know, in high school where you start talking about bits, you know, so I would never do that. But I certainly, I know there have been places that did that. I think they still exist. Gets a little bit harder because the stuff we're dealing with is so much more complex. But I certainly, I know there have been places that did that. I think they still exist. Gets a little bit harder because the stuff we're dealing with is so much more complex, but I think there's still people who have that philosophy. Like they start bottom up with, here's how we... Real bottom up. Lower than that. I mean, gosh, you know, say I'm going to start doing computing. Well, the first thing I got to understand is binary arithmetic. I mean, I know there are things like, there were things like that. I don't know if they're still there.

Yeah. There's this great book, Code, that I have somewhere. And it starts with flashlights and wires and builds up to a computer. It's super interesting. Right. That's a fun thing. But I'm saying the kind of details about how numbers are represented in terms of bits that I don't think you need to encounter that very early on in thinking of that computing. Although at some point it's important. I think you mentioned MIT AI research. Is that where this perspective that this book was putting down came from? Yeah, I mean, both Jerry and I were in the AI lab when we wrote that. So of course, that was doing programming in LISP.

That was really taking a sort of philosophical approach to what computing was about. So it was a very natural thing for us to do. And the book, was it well-received when the book came out? Yeah, well, it was well-received, I don't know, partly because it was MIT or something. But the thing I remember when MIT Press, when we first sent it to MIT Press for review, the first review came back and said, the question is whether this will advance computer science or set it back. I've kept that ever since. It's one of the views that I really, really love.

And it went on to complain that we didn't talk about the details of how you implement linear arrays. You also build something like Prolog in the book. Yeah, right. So when that book came out, remember, we were talking about programming paradigms, right? Because we were saying, gee, you know, there's sequential stuff, there's functional stuff, although we didn't use that. That language wasn't totally there consistently when we did it. But, you know, imperative, sequential stuff, there was functional stuff.

And in those days, the big thing like that was logic programming. And, of course, Prolog was being really, really big then and coming out as an alternate paradigm for how you think about computing. So we said, gee, from that perspective, we really ought to talk about something like Prolog. Because again, at the level of abstraction, it was sort of abstracting away the sequential order in which you said things. And in the vision of Prolog, you basically were saying, gee, what the answer should be. And then you sort of leave it to the guts of the language interpreter to kind of get there. Now that's sort of bouncing around. It's not nearly

as big a piece of computing as it was in 1980, 1981. So I'm not sure, I'm not sure that if we were to do a book again, we would do something like implementing prologue, but it might be because it's, you know, again, it's a very important idea. So I remember when I took a course that toured through different paradigms and the prologue one, I think it kind of broke my brain a little bit. Yeah, right. Like it was very, it's a very different model, but has it not succeeded? If you're thinking of you would drop it, does that mean it's been a less successful approach? Well, that's what I think, although I haven't been following it that much.

But it's not nearly as big an approach as it was when it was first introduced. Yeah, it really abstracts away how things get executed. Yeah, I mean, that's exactly, again, in the big picture of abstraction, that's one of the things that you abstract away. Yeah. When you were talking about abstraction, one thing you talked about was kind of abstracting over types, like being able to add things regardless of... Right. So do you think that dynamic types are important to this book? Well, it's not like they're important. It's like we just take them for granted. How else would you

expect anything else to work? How else would you expect anything else to work? I don't know. I've got a variable called x, right? Actually, x is, I don't know, the height of the room. I really have to specify whether I'm saying it's fixed point in inches or it's a floating point thing or if it's even a symbolic thing. I mean, why as I'm thinking about designing the program, do I want to think about the particular mapping of x onto, you know, some set of types. So dynamic types are like natural and static types are not? It's like, I don't even understand why you'd want static types if I get facetious, but I do, I certainly do understand. I certainly do understand that from a programming point of view and from a, you know, and even from a program design point of view, but why should, but why

do I want to worry about that right now? You know, as I'm designing a program, why do I really want to be thinking about the data types of my variables, at least at that level? Although, you know, I do understand when you get into much more of object-oriented stuff that having types in classes is another important idea of things to do. I just wouldn't start there. And I certainly wouldn't burden people writing the very first programs with that stuff. Yeah, interesting. Because there is people who believe that defining types is a way to express abstraction.

Absolutely. It's a very important organizational idea. Except I don't think that types like that, or whether it's fixed point or floating point, or string or something like that. I mean, that's what I said. I think at higher levels, when you really are thinking about object-oriented stuff in classes, having that type discipline can be very important,

both for designing stuff and debugging. It's just I wouldn't start there. If you want to tell me, you know, why in the world should I care about the difference between a fixed point number and a floating point number? Well, maybe if I'm doing numerical analysis, that's interesting. But I can't see when you're starting to program that way. Yeah, interesting. I'm doing numerical analysis, that's interesting, but I can't see when you're starting to program that way. Yeah. Interesting. I get where you're coming

from. Do you think that this kind of scheme Lisp culture has been lost? Well, I don't think it's been lost. I mean, look at JavaScript, depending on your view of JavaScript, you're saying, boy, it's wonderful. You don't have to worry about it. Or you can say, gosh, what a horrible thing if people are always making these errors and these errors with type violations. So you're kind of seeing it right there. But again, if I'm starting out, you know, even with college students, not to mention high school students, I don't want them thinking about that stuff. Yeah, no, that makes sense. So JavaScript is the inheritor of the scheme flame? Pretty much. As I said, it's got syntax to use. Well, it's got to be the most popular language right now, right?

Like everybody has an interpreter for JavaScript on like every device that they have. It runs on the browser, right? You know, so in terms of education or the fights between JavaScript and Python, they're duking it out right now. I don't want to predict how that will come out or maybe some third thing will come out. Oh, really? So that's a contentious whether we should teach in Python or JavaScript? Yeah. I mean, I think if you're looking at high schools and even introductory college courses, they're all sort of stuck in Java at the moment. And they're moving to, I'd say more to Python right now. And that's because Python, you know, it's just wonderfully interpretively. If you're teaching, it's just super important that you have some interface where you basically have a command line interpreter

that's an interpreter. You know, so Python has a tremendous advantage there. And then Python, you know, has these magic import statements. It's right, it's like magic. You want a whole bunch of capabilities, you find some library and you say import, and it works that way. That was one of the ways we blew it in the scheme. We didn't pay enough attention to import. You can do it. You have to tie two hands behind your back so you can do that effectively. Whereas in Python, that's really, really natural and it's a tremendous source of power. At the same time, JavaScript is now, as you say, built into every browser. And there's a much more fluid relation between what you write in your JavaScript program and what you actually see on your browser page.

So kind of what I think is happening is you're seeing JavaScript sort of take over more and more of that educational territory from Python. But, you know, there's a lot of great Python work being done in libraries there. So I don't think that fight is anywhere near over. Yeah, it seems like with JavaScript, if you could just have a browser extension so that you can modify the web as you use it, right? Like if I could have a little thing. That's what's sort of important. If you think about it, you're trying to introduce kids

and in general people to real power. Yeah. With JavaScript, it's kind of in your face that the power you're introducing them to is the power of the web. So that's a giant, giant advantage that's happening there. Yeah. When I started doing like computer programming, it was to build cool things. I guess now the more theoretical things sometimes excite me, but I don't think they would have when I was just like trying to print things.

Right. Well, you know, there's this whole information internet world out there and the fact that you can sort of touch it and modify it a little bit and shape it a little bit to what you think is important. That's enormously eddy and it's enormously important from an educational perspective. So do you think it's like easier these days to teach people about computer programming because everybody has computers and so on? Oh, way easier. I mean, just look at the kind of stuff that people are doing. So do people come to MIT with a lot more experience already? Yeah, they do. Although remember, MIT is like the extreme end of that spectrum. So I don't know that 10 years ago, we had a lot of students coming in whose background was having started software companies.

You know, whereas we have several of them right now. And it's all natural that they've done programming and they've done programming with stuff on the web. And they know hundreds of packages and stuff. That didn't happen, you know, certainly not before the last decade, although there were maybe one or two who were extraordinary. But now it's kind of common. Is that represent a challenge? Like, I guess, you know, this book's no longer being taught, but if somebody already knows to program in a bunch of languages and then you're like, here's Scheme,

does that influence their uptake of things? Well, I mean, we taught Scheme up until, was it five, six years ago? So it wasn't like it was originally. Like, here are these magical things that you could do that you couldn't do. I mean, Jerry Sussman, I should say, is teaching a course in advanced symbolic computing at MIT. He and Chris Hansen, who was kind of the head guru of implementing Scheme. And they've been doing a course that really, really, really pushes abstraction and modularity and has to do with what I was saying before about how you really think about you're designing a new language and really the idea of that book is how do you how

do you program in a way that you maintain tremendous flexibility to change what your program is doing and looking at some pretty advanced stuff that it's still in scheme but one of the key ideas in there is that you program things in terms of combinators. And you glue, it's the way you glue, it's the way you glue code together. And they have various combinator languages that do that. So they're still working on that. They've been teaching it for about two semesters now. And I think that book is about, is going to come out, I think they're going to give the

manuscript to MIT Press sometime this fall. So that means it'll be out in about a year. Okay. So is it in some ways like book two in this? Well, yes. I mean, it's like book two in that it really, really pushes this notion of linguistic theory of design and linguistic abstraction. Although it starts at a much higher level than that. Wow, very cool.

That's a book that people should look out for because basically the ax it's grinding is that, gosh, people think about writing programs and software as designing a program to do one particular thing. And then the way you, the price of that is that a whole lot of software engineering ends up being trying to dig yourself of the hole, trying to get out of the hole you dug yourself into because you made a program that was too specific. So that book is really, how do you not dig

yourself into these holes? And the answer is you use various kinds of programming styles and techniques like combinators to glue things together. That's interesting, yeah. I remember somebody in the Haskell world saying, the way you solve a solution is you should build a library for that class of problems. Right, that's exactly the same thing I was saying before, except you just said it, I think, more clearly and better.

There's the Xmonad windowing system. And I think that the configuration script for it is actually just you just write a program using their library that knows how to do windowing stuff. That's right. So those are all good examples of that. I don't think I've gotten to the level where I know how to do this effectively. It seems like that's the thing I can do the second time around. The first time I solve something, I solve a specific solution.

And then maybe if I... Right. And you sort of have to get enough practice so you approach it that way the first time around. Although it's hard. Yeah. I mean, I don't have the skill. It sounds like an amazing skill.

Maybe something for us all to learn from that book. Yeah. Well, I think what that book is trying to do is kind of to introduce the paradigms and the constructs and the examples that people would then start using. But we'll see. You know, it's just, as I said, right now,

right now there are only a few people who have even seen the manuscript for it. They did a bunch of revisions, gosh, three weeks ago, and they're updating the manuscript, and they want to give it to MIT Press in the fall. So the students are kind of the test run for the book? I noticed with this book, I mean, you talked about it a little bit and I think it's, this book came out of the same kind of process, right? Oh, yes. I would say that it is math heavy. Oh, it's very math. No, it's very,

very, very math heavy. That's because when we did that, we were doing it for the MIT freshman class. Everyone in that class, you know, was taking calculus, for example. So the fact that we would do an example and, hey, what, you know, our third example, whatever it is, has to do with derivatives of functions. Well, that was natural for those students, but certainly not, you know, certainly not for a different audience. So we would have done something totally different. Yeah, that gives us some context because, yeah, I was wondering, we're doing derivatives already? Yeah, right. Well, there have been examples. Somebody did a version for MIT sort of humanities faculty,

where instead of those examples, they did examples having to do with text manipulation and stuff like that. The same kind of interaction, just a different set of examples. Math is just like a domain that you can solve, you know, that you can use to solve. You can use these. Yeah, and then it was natural for us because everybody knew math and we were thinking about functions anyway.

You mentioned earlier about magic, right? And there's like a wizard on the front. Oh yeah. That's one of the paradigms a bit about programming is like magic. I don't know whether it still seems as magical. It certainly seemed magical, you know, magical in 1980 and before. I don't know if people still think it's magical. What makes it magical? magical in 1980 and before. I don't know if people still think it's magical. What makes it magical? Well, the fact that you sit down and you write these words and these words are like spells and they do stuff and you get these spells right. And God, something happens in this computer. At some point, we talk about conjuring. We talk about conjuring the spirit of the computer.

We actually got some complaints from a couple of MIT students saying, these guys in this MIT course are talking about witchcraft. That's funny. I don't think you'd get that complaint today. But maybe the era computers were more novel. That's the issue. I mean, now it's mundane. Yeah. I guess in some ways, if you're doing something that's magical and with computers that nobody has seen before, that's something that's lost these days. Oh, yeah. Well, that's going to continue, right? I mean, you know, I suppose you said, think of yourself five years ago.

Somebody said, well, it's going to be pretty natural that you can put this little box in your house that you talk to it and it talks back and can tell you anything you want to know pretty much. Five years ago, you would have said, gosh, what are you talking about? Maybe in 20 years. And now everybody in the world's got Alexa and Google Home or something. It doesn't even seem out of the ordinary. Yeah. And then it raises the bar on a cool project that somebody can do, right? Although at the same time you're raising the bar, you're raising the tools that are available. So gosh gosh, you know, let's write a program. Let's write a little system, you know, which like I do for fifth graders where they talk into their phone and say something and the phone says it back in German. So how do they do that?

They're using some. Because you've got these services on the web. You basically, gosh, I don't know. You have a thing where you talk into the phone. There's a service that translates that into text. There's a service where you send the English text and it sends you back German or Chinese or Spanish or any of 140 languages. And then you take that and you put it through something that pronounces the text. It's cool. So in the world of this book, you use a very small language and then implement the entirety of the language.

That's right. Right. Because what you have is you basically are looking at a different level of abstraction. So to say, you know, take this speech and render it into text is one operation. And you can think of it as one operation. So even though the bar becomes higher, the possibilities are also also become a lot higher. It's funny because in a way you were saying like, okay, I put out this book and people were like, what, you didn't even say the difference between arrays and lists. And now the abstraction level is way above that.

And people are like, well, we didn't even glue together APIs to remote machine learning services. Exactly. But I think that's why from a very high level point of view, this notion of abstraction remains. It's just that now you can abstract at a much, much, much higher level. But the notion that you can, what's the right way to say it? That you can deal with things of which you don't have to worry about the implementation details.

It's just the critical thing. Because it focuses on the language of the solution. So the levels don't matter so much, right? Well, it focuses on you can, you basically can work at a particular level and do whatever it is you want to do. And you don't have to dig down below that necessarily. No, of course, sometimes you have to, you know, if you're using the translation service and the network goes down, you have to, you have to think about what's happening there. The other thing is, is collaboration. I mean, let's put up a program

that lets you put up, you walk around town and you mark things on a geographic map and that map is shared and accessible by anybody in the country. Right. And I said, gee, five years ago, you're going to do that. You would have said, oh my God, that's incredible. That's insane. I couldn't possibly do that. Now everybody can just stick things on a map. Yeah, that's true. So I have this perspective that maybe because like computers are phones now and you use them to like look at Facebook or Instagram or whatever. But when I was a kid, the Commodore 64, it like started up and it was like a basic prompt. I don't know. Things are biased towards consumption, I guess. Oh, that's certainly, certainly, certainly true. On the other hand, you also can do things for production. You know, it's not nearly, nearly as common. But again, even with computers now, kids program them, kids can do some stuff.

And again, they can do amazing things. Of course, there are many more kids and people who just sit there and look at Facebook, but can argue about whether that's good or bad or something. But there's still the possibility of actually building really good things with those tools. Yeah, the trade-off, like just the power they have is so much more, but they may not do anything. Could be. You had this thing, something called App Inventor. Yeah, that's kind of what I'm sort of backhand referring to.

That's what I've been working on at MIT for the past few years that I started when I was visiting at Google. So the idea of App Inventor is that any kid ought to be able to build mobile apps. So we have this sort of drag and drop blocks programming interface that allow you to put procedures together for the phone and then run them on the phone. The example I said about making a map that everybody in the world can share, those are actual app inventor projects that are done by junior high school kids and high school kids. Wow.

But it's because you've got access to all of those services. That's one of the, you know, tremendous differences that's happened, that there really are these things on the web that people can go and grab. And of course, the next round, which is even starting to be here,

is those same kids will be able to use conversational interfaces. Yeah. So again, you know, if I said four years ago, you would have sort of said, well, yeah, maybe. And now every kid you know has played around with Alexa. So the idea that kids could build some stuff that can make Alexa do something doesn't seem nearly so far-fetched. Yeah.

Like my nephew. That's one of the things we're working on in App Inventor. Has it led to people pursuing computer programming? Well, App Inventor has only been around for, I mean, we started this as a research project in 2008. And there have been a lot of kids doing App Inventor. You know, Scratch is the other one that's even bigger coming out of MIT. So there are lots and lots. There are many, many kids who've gotten their exposure to computers through Scratch and App Inventor. But to do another piece of

research, let's say, okay, well, what fraction of those kids have gone out to actually do something in computers professionally or when they grew up or something like that? I don't think enough of that research has been done because what's so hard is that computers are so incredibly more pervasive now. But that's an important piece of work that needs to be done. Why does their pervasiveness affect it? Well, what's your test group going to be oh i see that's a good point yeah yeah i was just thinking like anecdotally has it been a success oh there's been lots of anecdotal stuff yeah but you know the other issue is the scale is getting so much bigger you know as i was saying with our app inventor thing we run off a server MIT. We have a million active users a month.

Oh, wow. Nothing anybody would have dreamed of 10 years ago. Yeah, that's impressive. That's great. Do you feel like this will encourage more diversity in the field? Well, I sure hope so. Because I think that's a really critical issue. And it's critical both in terms of how computing affects society.

And it's also even critical for the commercial interests of the companies doing this stuff. So I don't know what's the analogy. I still consult at Google, and certainly one of the issues inside Google is the diversity of people they actually have designing these products. Because at the end of the day, if you don't actually have a diverse design team, if you're not really creating products, you're just ignoring a whole percentage of the population when you think about making computational tools for people. And there's nothing new about it. It wasn't until, I don't

know the date, but not a very long time ago, that in automobile crashes, there was a much higher percentage of female fatalities. Just the fact that women would end up really worsened in automobile crashes. And it turned out that one of the reasons for that is the national safety standards didn't mandate that the companies use female-faceted crash dummies. They weren't even testing that case. And so when they tested it, they weren't even doing it. And the result was, you know, actually when cars got out, there were higher levels of fatalities until very, very recently. But that's a really extreme concrete example of there was a whole part of the population, in this case women, that these engineering artifacts were not designed for. Yeah, there's like also just like if you have a group, groups can make better decisions than individuals, but only if the group represents people with different backgrounds.

Exactly right. So what's happening is a lot of the companies like Facebook and Google and Amazon and everywhere are getting slammed for this and they're starting to realize it. But again, it's just starting. So, you know, you point that out as an issue. That's just a major, major issue that we have to address. Yeah. It'll take time, right?

You're on there at MIT, I assume is not a 50-50 male-female. I mean, historically what's happened, if you look in computing, the percentage of women is half of what you expect it would be. So, you know, at MIT there's about, gosh, you know, let's say it's about 50% men and women, but only 25% of the computing students will be female. Oh, I see. So whatever it is, it's about half of what you'd expect. And that seems to be pretty common. But it's a really serious issue that everybody needs to work on. And Google sees that in their recruiting.

Everybody talks about a pipeline product. Yeah. And at the same time, as computing products become more and more things that everyone uses commercially, it becomes economically important for these companies to appeal to as large a segment of the population as possible. Like, you mean they'll build better products if they're more representative? Yeah, they'll build better products. I mean, you can be totally mercenary. Better products could mean they're better tailored to more of the population, so they sell more of them.

You know, whatever your definition of better are. But even from the most mercenary point of it you want to have that kind of diversity you know like in machine learning they have bagging they take like several learning algorithms and put them together and then you get a better result you know if you have diverse backgrounds and you combine them like you probably know the amazon hiring example which is a big fiasco no oh amazon was it last year two years ago, basically did a machine learning thing to help evaluate resumes of who they would hire. And it turned out that if you had a resume

that mentions that you did something as a woman, the program scored you lower. All you had to do was include the stuff about women, even with everything else the same, the program scored you lower. So it turned out that when Amazon looked into this, what was happening, they were training the data on the CVs of their Amazon employees, which of course had very, very few women. So what happens, you know, the standard thing that goes on now when you build these machine

learning things, or until very, very recently, you try to train them on the data that's there. And the data that's there is biased. So what happens is that your machine learning program just perpetuates the bias. Yeah, I had Corey Doctorow on as a guest, and he was talking about in Oakland, they did some sort of machine learning on arrest data. And basically, it just learned the bias that was present in the existing system. Right. All that predictive policing. And that one's really easy to understand because what happened is if you want to get more arrests, you just assign more police to a place, right? So even if the crime rate's the same, you'll get more arrests if they're more pleased. So what happens, that sets up this positive feedback loop where this machine says, assign more police to this place.

Guess what? There are more arrests. Guess what? You should assign more police there. So that one's actually pretty easy to understand. Yeah, second order. But there are ones that are just way, way more subtle than that, right? Having to do with the ages of people and just lots and lots of stuff.

It's a hard issue. You know, the companies are really, really trying, but they stumble over this stuff because they train on the data that's there. And the data that's there is often biased for historical reasons. And then you just have your system that perpetuates the bias. So I'd like to ask you about something else. I was watching this video, I think it was an interview you did for MIT. And you were talking about the early days of the MIT AI lab and talking about some of the culture. And one thing surprised me, which was like that you guys didn't have computer passwords. Everything was kind of open. Sure. Well, come on there. That's the standard thing that everybody realizes now that everyone will say the internet actually

before the internet, you know, the ARPANET and all that stuff was made for a bunch of nerds like us, right? So nerds like us are people like us. We're not going to try and do anything to subvert the system. We all are fairly intelligent about how the system works and we all have a shared goal to make it better. So why in the world would I want to try and protect against people like that? So the fact that there were no passwords is just an example of that. I mean, why would I need anyone to have a password? No one's going to do anything bad. So one of the big real shocks that's finally gotten into the,

even the computer networking and computer science communities, guess what? There are bad people out there. Quite literally, nobody actually thought that you had to design the network against bad people. You know, and there's some fundamental flaws in the way the internet's put together Quite literally, nobody actually thought that you had to design the network against bad people. You know, and there's some fundamental flaws in the way the Internet's put together that come from that initial sort of naivety, of which the biggest one is no verification on DNS. Right. So, you know, when I connect to a website and say, hi, my address is 18.43.0.79, the thing I'm connecting to believes me. Oh, OK. 43.0.79, the thing I'm connecting to believes me. Okay. And look at all the spam, look at all the fake messages that come through, look at all the malware that comes from a forged place.

I mean, that's major, major, major vulnerability in the network right now. And it's simply because nobody thought at the beginning that if I connect to a website and I advertise my address, well, sure, I'm honest. Everyone should believe me. So we're paying for that right now. But is the success of the internet related to this initial openness and naivety? You got to be a little bit careful. I mean, you can say that. It certainly made things easier. But there's a difference between openness and verification. If I send you a piece of email, you can certainly design your system so that anybody can send you email. But at the same time, that doesn't contradict that whoever sending you

email has to verify that they're really coming from the address that they're saying. Of course, what I just said is kind of controversial because that doesn't really allow anonymous email. But the fact that you're putting prohibitions on something and authenticating, those aren't necessarily incompatible. And as I said, the major one is DNS security, where there's just no, hey, I connect to you and the site that's getting the connection believes who the connection's coming from. It can still let anybody connect, but it might want to verify that that's really the address that's coming. It's interesting that you're pointing out problems with security caused by this openness, because I was thinking that you, you know, would be very for that culture of initial openness. Well, but again, don't confuse openness with the fact that you can

verify what people are doing. I mean, certainly it's way, way advantageous in the network to let anyone connect to some site. That's really critical. But that's different from saying, when I connect to a site, the site you're connecting to can verify that that's really the address that you're advertising. Yeah, that makes sense. Hey, look what's going on right now with spam phone calls, right? Anybody can call you and that's okay. Or maybe not. On the other hand, these days people are forging the number they're coming from. That's not okay. Yeah, I guess that's the same problem. I never thought of that. Yeah, they can spoof the callback or whatever.

Yeah, so it's a real pain in the neck. So now they're talking about putting in these protocols so they can't spoof them as much. But again, there's a difference between spoofing your address and whether or not you're allowed to make a call in the first place. Yeah. On the topic of openness, you co-founded the Free Software Foundation? Yeah, I co-founded the Free Software Foundation. I also co-founded Creative Commons much later. So the Free Software Foundation was what, 1985?

Creative Commons was, I think, 1999. But they come out of the same idea. That idea being like to encourage an open culture on the internet or what? Well, I mean, the Free Software Foundation is trying to say that dealing with software is kind of a human right. So if there's a program, you know, anybody should be able to use it. Anybody should be able to modify it.

And anybody should be able to redistribute it. Because it was saying in those days of software, and even now, you want to view these computer programs as a resource of civilization. That's really the philosophy behind it. That's really what's behind the GPL, the general purpose license. It's saying you want to have those rights. And then if people restrict those rights, various bad things can happen. Like, gosh, if no one can look at the source of your program,

how do you know there's not malware there? That's true. But there's lots of software that's not GPL that's out there running that doesn't have malware in it. Oh, sure. Yeah, of course. But the point is,

you sort of beholden to the people who can see the source of the code or own it or put proprietary restrictions on it. But, you know, certainly what you say is true because it works at all. But there's a lot of security that would help if the sources of programs were around for everyone to examine it's not magic right because the big

country the big contradiction to that of course was heartbleed which was around and sourced for a long time nobody noticed it yeah that's right there's not enough eyes in the world it seems to yeah that's right yeah did you expect the free Software Foundation and the GPL to be as successful as it has been? I don't think so. It was so hard to look back because now we're talking about, you know, millions and millions and millions of people using stuff. And when the stuff was made, it was, oh, cool, you know, we might get a thousand people to use this and wouldn't that be great? So it's so off scale that it's hard to say what's expected. You know, when we started Creative Commons, you know, even in 1999, we're saying, well, what would be great success for the Creative Commons license? Oh, wow. You know,

if we got like a million people to license this stuff with Creative Commons, wouldn't it be marvelous? You know, and now we're in whatever it is, one and a half billion or something. So there's a whole scale that's grown together with access to the internet that makes it very hard to answer the question, like, did you predict it would be this successful? Yeah, well, it certainly has been successful. Now, like Google is running lots of GPL code, but because they offer cloud services, their code will never be accessible. Google doesn't use GPL so much anymore, right? Google tends to put releases stuff under Apache, although there is a tremendous amount of GPL stuff going, which you won't see Google use as a GPL. Yeah. Because that's the stuff that runs on their

server that has all the secret sauce. Yeah, because it seems like the new cloud-hosted companies, like whether something is GPL or not, is less important. Yeah, because it seems like the new cloud-hosted companies, whether something is GPL or not, is less important. Yeah, right. That's right. That's why AGPL is there. And that's also why you don't see the cloud-hosted companies use it. Yeah. So it's like you won, but... Well, based on where it started, the idea that there would be lots of places, lots of commercial companies using this stuff would have been really super. Wasn't it Microsoft who at one point back then said the GPO is like communism? Or like cancer or something.

Yeah. Maybe it's cancer or something like that. Now you see Microsoft putting out all sorts of GPO stuff. Yeah. So, you know, there's a long way to go, but don't say that nothing's happened. Oh, I'm not saying that. Yeah. I just feel the context has changed because a lot of software isn't running on my personal machine. Right.

And the GPL is really from the world where the software is running on your personal machine. And you, in fact, are in control of it. You know, the big difference now is the stuff has gotten so complex, it's not reasonable, mostly, to say that you're in control of the stuff that you're using. And yet, somehow, you still have to think about how you preserve those fundamental rights in this new environment. Yeah. And how do you? Like, it's open question. I don't know. I think that's a real, real challenge. And then, if you build something open source, if you build an open source database or something, Amazon will probably make money running it on its servers. Oh, sure. I mean, that's the other sort of societal issue, which is it's the places like Google

and Amazon and Facebook, because they control so much data, forget about the software at all, that they're in a much better position to get advantage from the software being out there. So that's a whole thing that people haven't confronted yet, that you sort of say, well, you know, we put out the software, the software is free, software is doing all this stuff. At the end of the day, that does not lead to a more equitable society, because these places that already have control of the data are really the places that are making the most profit over it, even though everyone has the software. So that's a really, really serious issue. I don't quite know what you do about that. And I don't know that people have really, really confronted it, but it's a real phenomenon. Yeah, you could say technology empowers all,

but that's not true if it's like machine learning and you don't have the terabytes of data to get a useful result out of it. Yeah. So I think people are going to be noticing that more and more, but I don't know that they're quite the ideas there yet. So I wanted to kind of wrap up by asking you about the book. So you mentioned if you rewrote it, you might drop prologue. The book's been out for a long time. You know, what would you change if you were doing it today oh we did not do nearly enough on object oriented stuff so when we were doing it you know we did a little bit of it how you define objects we did uh you know pretty primitively how you would create uh how you'd

write procedures to build new objects so let me say it a different way as i think about it when we talked about objects, we said, gee, what's really important is that this object is encapsulating local state. So if you look in like chapter three of the book, that's the whole message. It's a great thing that you can encapsulate local state. We didn't at all talk about abstractions like classes and how different kinds of, how you'd organize different kinds of objects into classes and what that whole thing would be like. That's become tremendously important, and we just didn't appreciate that at

all. It's interesting because I feel like the book is popular with people who are kind of functional programmers who would reject your idea that objects are important, maybe. I know, that's what it's how to go with the state monad and all that stuff. Well, you know, that book probably did more functional programming than any other book that came out at that time. So we pushed functional programming a lot. But I don't say, but we certainly didn't take the idea that you should always use only functional programming. Yeah, that makes sense. Partly because we didn't know how, right?

I mean, Haskell folks have done a way better job with that than we have. I mean, I think there's still some things that are awkward to do in a functional. But we didn't even think about that. We said, gosh, a natural thing you want to have to do is deal with state. But anyway, I think we didn't really talk about how you use class classes and how you think about subclasses and superclasses and how you organize the world that way. And then, of course, another thing that we didn't do is we didn't think about interactivity at all so do you mean like interactivity in terms of like an ide or like a repl or activity like i want to process a mouse click oh yeah yeah not to mention

all the stuff you're talking about yeah but we didn't you know even think about those kinds of programs at all it's interesting because so it has some stuff on streams. But our streams are very, very functional. But some people deal with interactivity now by actually like, oh, here's a stream and events will come in. Yeah, we talked about that. And we talked about, yes, you can organize a program that way. But I'm not sure. I know I've never tried doing a mouse handler that way, although I assume you can. Yeah, I think it's possible. But yeah, so I guess another perspective is, you know, you wrote this book, 1985, and you were kind of introducing this different way to think about computing. So like if you were writing a book today about computer programming, that was going to be like a new way to think about computing, like what would be in it? Well, I would

be, our book was kind of self-contained in the sense of it's about the programming stuff. But certainly if I'm doing education now, it's much more about what's the environment that you can program in. You know, how would you talk about the web? How would you talk about getting other services? You know, these days, what's one of the most important concepts that you want students to know about? And the answer is it's an API. It's the idea of an API. I mean, you can say that that's abstraction too, but I'd certainly want to talk about the possibilities of what you can do with programming. Would it even be a book then? Or would it be like your app building tool? The Ad Inventor thing's a platform and it's mostly for younger kids. But certainly if I'm writing a

book, I would talk about that. And as I said, in some sense, Python really is the one that did that not exactly right in terms of APIs, but in terms of import, you know, and say it's not only you writing this program by yourself, it's there's this whole world of libraries that you can take advantage to. So Python is really, really did that well. And I try to get that sense into a book. Yeah, because there's like programming in the large, I guess, like you talked about Google, right? All kinds of things, like not just imports, but, you know, reviewing each other's code. And I'm not sure that I would talk about that. Certainly when you get to a more advanced course, you do that. And certainly, you know, hanging out at Google is part of that culture too. And

it's very, very impressive. And Google certainly takes that extremely seriously. It's wildly important. But I don't know that that'd be an introductory question. Well, this has been a lot of fun. Hal, thank you so much for your time. Okay, well, if you've got more questions, just let me know. Max, thank you so much for requesting I talk to Hal. Everyone else, if you have recommendations, let me know. You can hit me up on Slack.

There is a suggestion form on the website in the top, or just shoot me an email or leave a comment. I love to get suggestions about guests. If you listened this far, I hope you enjoyed the interview. Until next time, thank you so much for listening.