The Python Podcast.__init__

Share on social media:

[00:00:13] Unknown:

Hello, and welcome to podcast dot in it, the podcast about Python and the people who make it great. When you're ready to launch your next app or want to try a project you hear about on the show, you'll need somewhere to deploy it. So check out our friends over at Linode.   With their managed Kubernetes platform, it's easy to get started with the next generation of deployment and scaling powered by the battle tested Linode platform,   including simple pricing, node balancers, 40 gigabit networking, and dedicated CPU and GPU instances.   And now you can launch a managed MySQL, Postgres, or Mongo database cluster in minutes to keep your critical data safe with automated backups and failover.  

Go to python podcast.com/linode   today to get a $100 credit to try out their new database service, and don't forget to thank them for their continued support of this show.   Your host as usual is Tobias Macy. And today, I'm interviewing Charles Petzold about his work on the second edition of Code, the hidden language of computer hardware and software. So, Charles, can you start by introducing yourself?  

[00:01:08] Unknown:

Hi. I am Charles Petzold, as you just said. I have been writing about computers and computer programming since about 1984.   1 of my major achievements is a series of books about   programming applications for Microsoft Windows.   But in 1999,   I wrote   a book called Code, the hidden language of computer hardware and software, which   begins at a rather simple level   and eventually describes how computers work.   That book has just been revised for a second edition. It came out, like, 2 months ago. And do you remember how you first got introduced to Python?   Python.  

No idea about Python. Never coded in Python.   I've coded in Fortran. I've coded in PL 1. I've coded in APL. I've coded in basic,   Pascal, c, c plus plus, c sharp, JavaScript. Never coded in Python.   Never wrote about Python.   Have no idea why I'm being asked about Python.  

[00:02:06] Unknown:

Yep. That's 1 of the joys of being on a general programming language podcast, this 1 being about Python. But Oh, really? Okay.   The reason I have you on here is because the principles that you're covering in the book are broadly applicable regardless of what language you use. And so it's interesting to be able to dig into some of those fundamentals, but Okay. It's always fun being able to throw a curveball. Well, I I guess I didn't research your podcast as well as I probably should have. Oh, no worries.   So digging more into the book itself, you gave a bit of an overview about kind of what it encapsulates, but I'm wondering if you can give some of the detail on the focus and the goal of the book and some of the story behind how you decided that this was,   an endeavor that you wanted to embark on, trying to figure out how to kind of   all of the details about how computers work in a way that is   generally and broadly approachable?  



[00:02:59] Unknown:

Yeah. Well, back in the late seventies,   I got involved in building electronic music instruments for my own personal use.   And, eventually, I built a digital   music synthesizer   that was capable of generating   80 sign curves in real time.   In order to control this thing, I built a z 80 based computer.   Prior to starting   messing around with electronic music, I   had no background in digital electronics at all,   but managed to teach myself some of the stuff from books and   started wiring up integrated circuits and getting a good understanding of what was going on.   I was building something, and I realized I could, like, put codes into memory   that would instruct the hardware what to do. And I realized I was reinventing a microprocessor   at that point, which allowed me to actually investigate using microprocessors. And at that time, Intel 8080 was becoming real popular. I eventually used a Zillogg Z80   for my machine because it was a superset of the 8080.  

So that was kind of the background of how I learned about this stuff. But   later on,   I started writing for PC Magazine in 1984.   And a couple years later, I was given a column called PC Tutor where people wrote in with their questions.   1 of the questions somebody wrote in was, he was learning assembly language,   and he understood,   obviously, the addition and subtraction   operations in assembly language, but wondered about the and and the or, what they were for.   I answered this question by going into the details of how   logic gates   could be wired together to add 2 numbers together   binary numbers together,   binary digits together, and then cascaded to add larger binary numbers together. My editor was very impressed with this. He had no idea about computers added numbers together, and I I discovered that a lot of other people did not either.  

That put the idea into my head of maybe   orienting a book around   starting with very, very basic principles   and getting to a point where the book could show how binary numbers were added inside a computer and maybe go beyond how other parts of the computer worked. And this   idea   rattled around in my head for about 10 years   until I finally   decided to try writing it.  

[00:05:32] Unknown:

In your effort of writing this book and going through what I'm sure was probably a rather long and detailed process,   what was the,   I guess, persona of who the target audience was as you went through the efforts of actually putting pen to paper and trying to figure out what is the appropriate sequencing and the appropriate level of detail.  

[00:05:52] Unknown:

Yeah. At the time that I was first working on it, I   told people that a lot of the other   programmers I talk with, we had this common problem where our parents did not understand what we did for a living.   So I said, this is a book for the parents to understand what computers were all about. I think that was partially a joke. I'm not sure at the time.   So I guess I was writing it for somebody   who   did not know the real basics. And by the real basics, I mean,   logic gates.   What I discovered   after the first edition was published was a lot of professional programmers   don't know this stuff either.  

They either   kind of glided through it in college without really grasping it or   just,   you know, picked up programming on their own and didn't have this background. So they were kinda curious about it.   I've also heard from   high school teachers who have used a book in   like an advanced class in high school where the teacher picks out some students who might show an interest in computers. I use this book to get a first glimpse into what goes on inside. So   I didn't really know who I was writing it for,   but it turned out a lot of people enjoyed it. 1 of the   interesting things that I did   was in order to show how logic gates work, logic gates are built today out of transistors that are microscopic   on chips.  

But   I didn't wanna discuss how a transistor worked   because   when you get right down to it, it's complicated.   What it does is fairly simple as a switch or an amplifier, but how it actually works, It involves quantum mechanics and, jeez, I don't I just didn't wanna get into that.   So instead,   I   realized that early computers were built out of relays.   These relays   had been,   I think, invented for the telegraph system back in 19th century. They were later adapted for   telephone switching circuits.   But a relay is   much simpler to describe because it's just an electromagnet.   You wire around a iron bar and it puts circuit through it and functions as electromagnet.  

And then you wire 2 relays together in 2 different ways and you get and and or gates. So I realized that I could discuss. And once I got this idea   of relays in a telegraph system, it was like, oh, you know, Morse code   is kind of a binary code.   It doesn't appear to be exactly a binary code at first because you're dealing with dashes and dots and you're dealing with pauses between the dashes and dots.   But if you look at it as a stream of off and on,   it really is a binary code.   And then I started thinking about   sending Morse code with flashlights,   which I did as a kid.  

And that's really where the book starts. The book starts with hypothetical   couple of 10 year olds living across the street from each other, wanting to send each other messages at night,   figuring out that waving the flashlights in the air to make letters is not a good approach, but Morse code is a much better   approach. And then from there, discussing electricity with regard to the flashlight and then showing how flashlights can be wired together in various ways over long distances   and then going to the telegraph and relays and then relays can just and logic gates and performing and and or operations. And then you take a few of them and you put them in a various way, and you can add 2 binary numbers together. And then you can get the sum and the carry, and you can cascade the carry over into another 1, and all of a sudden you're adding 8 bit binary numbers together.   And that to me is the   the gist of the first half of the book. If somebody, let me check what chapter that is. It shows you how to adding with logic gates. It's now chapter 14   out of 28 chapters.  

And if somebody tells me they read up through chapter 14,   that's fine.   They got a lot out of this book.   But deeper into the book, I start putting these adders into,   arithmetic logic unit that forms anyway, so all that stuff. I'm making memory out of flip flops.   In 1 sense,   everything is built from relays, which people can understand, I think, much better than transistors. Although at a certain point, I say, you know, eventually, they abandoned relays for making computers and went into vacuum tubes and then transistors and then ships. But it's the same principle. It's just a little   switching circuit that can be wired together in a couple different ways. And from there, everything is possible.  



[00:10:46] Unknown:

I like the   opening metaphor of the kids with the flashlights   where they wanna be able to send messages and then quickly realize that they're trying to reinvent something that has already been invented,   which I think is analogous   to the experience that a lot of software engineers have when they are trying to, you know, figure out how do I do these more low level things that have already been done before. Oh, people have sorted numbers before.  

[00:11:13] Unknown:

Exactly. It's funny how a lot of people end up kind of reinventing   things, and that's it's a good exercise. It's really good.   I   have,   I guess, an engineering background in the sense I have descended from a couple of engineers   on both sides of my family. So I approach almost everything as an engineering problem.   What is the problem? What are the various ways to solve it and devise solutions to it? It's just   a a way of approaching   life in general.  

[00:11:45] Unknown:

Exactly.   The engineering perspective is definitely a valuable 1. And looking at the book and talking to you about sort of your sequencing is interesting to me as well as somebody who went through a degree program of computer engineering, not just kind of pure computer science. And   from what you're saying about getting feedback from a number of software engineers about not really   knowing how things are done,   I'm wondering   as a continuation of that   topic of reinventing the wheel and not really knowing how things are done and having to rediscover it, what you see as some of the concrete benefits of   reading something like your book Code and   informing, I guess, software developers or peer computer scientists   about the more   foundational   mechanical aspects of how computers function as a way to be able to gain a better understanding of what they're actually doing and what the computer is being instructed to do when they write certain pieces of code?  



[00:12:44] Unknown:

That's an interesting question, whether   programmers using high level languages these days really   need to know this stuff.   Back when I was first   writing the first edition,   when I was coding for the IBM PC in the eighties nineties, a lot of us use c. Either we started with assembly language and then we use c.   And for me,   having   an assembly language background   when you get to start coding in c was essential.   People who did not have that background,   who encountered   pointers   in c,   were, like, a little mystified about what these things were.   And those of us who had assembly language background, we knew what pointers were. We knew what tables of pointers were. We know what pointers the pointers were because we had used them in assembly language. And so   going to c was, like, nothing for us.  

And so I always thought that having this   background, at least in assembly language,   was vital for high level languages.   Nowadays,   high level languages really don't want you to be use pointers.   My big language was c sharp, and you can use pointers in c sharp, except it's not easy. You have to you have to say you're you I'm using unsafe code.   So at this point, I don't know.   Can somebody   learn a high level language   and treat the computer as a black box   and be successful?   I suspect so.   I still have this feeling though that it helps to know what's going on inside.   It helps to know what kind of   code your program is being compiled into   and   how that is actually being processed by the hardware underneath.  

I can't give you a good reason why I think people should know this.   It's just a feeling that they should.  

[00:14:45] Unknown:

Yeah. 1 of the terms that I can't remember how or where I came across it, but has always rung true to me is the idea of mechanical sympathy, where even when you are working at a high level and writing in something like Python or c sharp or Java,   the code that you're writing at the end of the day is being run on that underlying hardware. And so if you don't understand even at an abstract level   what the computer is being instructed to do, you know, how does loading data from disk into memory and into the CPU registers and some of those different   aspects that are handled by the virtual machine or the compiler,   you end up writing code that is inefficient,   and you just kind of brute force it through because the language makes it easy, but it's not really the way that   is actually going to be beneficial to achieving your end objective because because you're going to be wasting a lot of cycles, wasting a lot of energy,   particularly as you move from a very simple problem into   a larger scale problem, particularly when you need to bring in distributed systems concepts.  

So that just principle of mechanical sympathy of understanding even in an abstract sense, when I tell the computer, you know, add a+b, this is actually what it's doing. And if I try to tell it to do it a 1000000 times, then, well, I'm really really gonna be adding a lot of hurt where I might be able to optimize it even in a high level language. Yeah. It's good to know that the microprocessor  

[00:16:09] Unknown:

is not   executing things at infinite speed, that there's no clock cycles involved.  

[00:16:15] Unknown:

Exactly.   And   the other aspect of the audience that you were discussing is not the software engineer, not the technical person necessarily, but people who just interact with computers on a daily basis as, you know, these days is mostly everyone.   And And I'm wondering what you see as the benefit for that group of people to be able to have at least some conceptual understanding of what computers are doing and how.  

[00:16:42] Unknown:

I hope that for those people, the book demystifies   computers.   A lot of people tend to think of what goes on inside a computer as magic of some kind,   and   I would like to dispel that. It is not magic at all.   And so once you get to a point where you understand that it's just little circuits doing this stuff, I think the computer becomes a lot less scary.   Maybe not. I don't know.  

[00:17:11] Unknown:

At least your fears are more focused   instead of just generalized to the entire computer.  

[00:17:17] Unknown:

Yes.  

[00:17:19] Unknown:

And whenever somebody's embarking on a project that's as ambitious as this 1, it's interesting to understand   what your thinking is as far as how you decided to   kind of sequence and segment the   journey through the book and   how you worked through understanding what is a useful balance of managing the density and quality of information that you're presenting with the desire to keep the pacing appropriate so that people can actually read through it and not get, you know, halfway into chapter 2 and put it down and never pick it up again?  

[00:17:54] Unknown:

Yeah. This is something that I struggle with a lot, and I   struggled with it when I was writing programming tutorials,   programming Windows series,   books that I wrote   of how to present the material in a logical order. And for those books, I would   often   divide the various topics into chapters.   And for each chapter, I'd I'd   write the chapter title on an index card,   and then write the dependencies   of that chapter on the card and then sort out the cards so that I didn't have any forward dependencies.   What I really dreaded doing   whenever I was writing a book is saying,   this will be explained in more detail in chapter 8. For now, you're just gonna have to accept that this is this is this. I   just tried to avoid that as much as possible.  

Depth of the material and the ordering the material changed a lot between the first and second editions.   In the first edition   let's see how the first edition went.   I   showed how a circuit can add binary numbers together.   I showed how flip flops could be used   to construct   arrays of memory,   and how selectors and decoders could be used   to address a particular   bit or byte of memory.   And from there, I showed a circuit where   that you would store numbers in memory, and then you set the circuit running and the the circuit would   sequentially   access these numbers and add them together.  

And then I showed another circuit where you could actually have codes in memory   that indicated with whether the next number is to be added or the next number is to be is subtracted from the sum. And to me,   once you start putting codes in memory   that control the hardware,   software and hardware have merged.   But 1 of the themes of this book, I'm not sure if it comes through exactly, in that hardware and software   are there's a continuity between hardware and software.   All that software is,   really, is codes that trigger   circuits   signals in circuits.  

And in the first edition, once I got to that point,   I said, okay. Now you understand   kind of how   a processor works. Then I went into   a long history of computing and then discussing   2 microprocessors   in detail, 1 of them being the Intel 8080.   And I was always dissatisfied with that because I didn't think I went deeply   enough into how the computer works. So in the second edition,   I start building   a subset,   the 8080.   This subset   executes   more than half of the instructions   of the 8080.   But I show how the arithmetic logic unit could be constructed,   how a register array could be constructed,   and how   signals could   be generated to control these things based on the machine codes.  

Whether   people are gonna hit these chapters and start screaming in pain or whether they're gonna say,   oh, so this is how it works.   I don't know. Maybe some will some   who knows?   But I was more satisfied with that.   Along the way,   in the first edition,   I didn't discuss   ASCII   until later in the book   in the context of different ways of encoding characters.   In the first edition,   there was a mention of Unicode,   but barely more than a mention.   In the second edition, I really wanted to go into Unicode in more depth because it's, I think, Unicode has been 1 of the more more important   standard developments in the personal computer industry. And at the various   least, we can send   emojis from Android to iPhone   and they translate right. That's all because of Unicode. And   at the time I was writing this chapter, I got an email   from the ISP of my major website   where the title of the email,   instead of having an apostrophe, it had 3 characters that had nothing to do with an apostrophe.  

And so you see this a lot. And, you know, every computer user has seen this and it's like,   what on earth is this? I know that should be an apostrophe. Why is it?   So   I decided to go for into a discussion of the Unicode transformation   formats. And discovered doing a little research that like 99% of all websites use, UTF 8 at this point. So I have a discussion of UTF 8, how it works, how the bytes are converted into characters.   So that was 1 of the big changes for the second edition.   The first edition   had discussion   of UPC codes   and how they worked.  

I used an example of the UPC code for a can of Campbell's chicken noodle soup.   That UPC code had not changed in 20 years   when I wrote the 2nd edition. But for the 2nd edition, I also discussed how the QR codes work.   Using the QR code for the companion website   of the book, which is code hidden language.com,   which has a bunch of interactive   circuits that you can play around with.  

[00:23:27] Unknown:

That's another interesting aspect of the book is that you do have all of these circuit diagrams to be able to illustrate the concepts that you're addressing. And   I know that the diagrams themselves, you   coded yourself, and I'm wondering if you can maybe talk to some of the process of how you decided to embark on actually writing the code to generate the circuit diagrams versus just, you know, drawing them out by hand or using some other, you know, circuit diagramming utility that already exists?  

[00:23:54] Unknown:

For the first edition,   we had an actual   graphic artist   do all the illustrations.   Most of them, I was very happy with.   I realized in the second edition, I would   need   more diagrams because I was doing different things.   And some other project I was doing,   I had   written this program   where you could   basically   code a diagram in c sharp, and it would generate   an SVG file, scalable vector graphics. I was using SkiaSharp for this.   So I started doing some of these circuits   just as c sharp code to generate them   for the book, the additional circuits,   and I realized to be consistent, I would need to redo them all, every circuit that was in the book.  

At the same time,   I wanted to do this website.   An interactive website for this book had been in my head   for years. It just seemed like a logical thing to do.   But I'm fortunate that I didn't do it years ago.   Because   years ago, I might have decided to do it in Flash.   And then at some point, I might have decided to do it in Silverlight.   But now   what we have available is the HTML 5 canvas,   which is   likely to be around   longer than Flash or Silverlight.   Likely.   Do you agree? I don't know.  

[00:25:28] Unknown:

It has more people supporting it   versus Flash and Silverlight, which were, you know, backed by 1 company and not really anyone else.  

[00:25:37] Unknown:

Okay. So for the website, of course,   I would be using JavaScript. And, see, I'm basically a desktop guy,   and then I was doing mobile.   And so my knowledge of JavaScript   prior   to 2021   was minimal.   So, basically, I needed to learn JavaScript, of which, of course, is fairly easy except if you're, you know, an experienced programmer,   except for the weird stuff in JavaScript. I am an advocate of strongly typed languages, so   I did not warm up to JavaScript very well. And in some cases, I was doing the same   circuits   in c sharp and SkiaSharp to generate the illustrations for the book and in JavaScript for the website.  

And I decided to at least try to consolidate these in some way.   I wrote both programs to use JSON files that would describe the circuits.   So, basically, the whole website is there's a bunch of support code,   but each of the circuits is defined by a JSON file.   JSON, I was not really thrilled with either, but it's you know, you use what tools you have.   So that was probably a long explanation of too long explanation   of the illustrations for the book and the circuits on the website.   But some of them   it turned out very few of them actually use the same   JSON files, but I tried. I tried.  

It was a lot of work. But I had everything under my control,   which is, I guess,   1 advantage of doing it all myself.   It   was a lot of work. Yes.  

[00:27:15] Unknown:

Yeah. Well, it's just like with everything in computing. It's a time space trade off.   And I always appreciate getting into some of the motivations and details of people's decisions like that. And, you know, why did you write your own language or write your own code for it versus just use something that was off the shelf? Well, because I wanted to have more control.   It's always a good reason.  

[00:27:36] Unknown:

I had to do the, my the website myself. I mean, really, was I gonna farm that out to somebody?   I guess I could have. I don't know.   You know, even though it looks like a whole team wrote this book in the website, and then now it's just just me.  

[00:27:53] Unknown:

It's very evident that there is a good amount of pride associated with it as well. So That's it.   And   1 of the other interesting aspects of this book is that I know when you first wrote it, your goal was to say, I'm gonna write this book once. It'll be done. It'll be that way forever. I never have to revise it, and here we are talking about the second edition.  

[00:28:13] Unknown:

Edition. So Yeah. But it lasted nearly 25 years, which Which is an eternity in computing. Oh, yeah. Yeah. I I was I mean, this first edition was still selling   quite well,   and I did not need to write this do the second edition.   I wanted to myself because of the flaws in the 1st edition. And the 1st edition I mean, there there's some things that had become a little dated.   I mentioned that the Unicode problem.   1 of the examples   of how   there's a chapter called bit by bit by bit, which shows how   bits are apparent in our day to day life. And that's the chapter that discusses the UPC code in the first edition and adds the QR code in the second edition. But in the 1st edition,   I showed a roll of 35 millimeter film   and how   boxes   on   that roll of film   indicated the ASA rating,   and they were read by the camera. So you put a roll of film in a camera, and the camera knows the ASA rating of the film.  

Magic.   And I thought that example really had to go. It just   people   haven't seen rolls of 35 millimeter film for a long time.   Except some peep I know there are some people who still swear by it, but   most people know.   It eventually gets into high level programming.   And for the first edition,   I decided to use, as a main example, an archetypal language   that was extremely influential,   and this language was Algol.   Nobody, except possibly a few retro computing enthusiasts here and there, have coded in Algol for decades.   But it was influential. It has the same that's block structure that we see in c and Pascal and PL 1.  

But for   this second edition,   I wanted a language that people could actually play around with.   It used to be the case that IBM PCs came with a little basic interpreter.   You boot up the PC without a disk in the drive, and you'd go into this basic interpreter.   And I really wish that IBM   and Apple had put the simple just a simple little basic interpreter   on their machines. And in that case, I would have used basic as a sample language. But I want to use a language   that people didn't need to download anything for. People could just play with on their computers use. And so, of course, that language, of course, also is JavaScript   because you can write just little   HTML files in Notepad and load them into your browser. So   1st edition, Algol,   2nd edition,   JavaScript   as a sample lang high level language.  



[00:31:02] Unknown:

Yeah. Obviously, there have been a lot of changes in   kind of the language ecosystems,   the architectural patterns of how people are building software,   but the kind of fundamental structures of computers have largely remained unchanged. There are some differences where we went from spinning disks to flash drives and, you know, CPUs have gotten faster and some of those architectures and instruction sets have evolved, but the basics of how they work is largely the same. It's still based around the Von Neumann architecture.  

[00:31:30] Unknown:

Yeah. I know CPUs are much, instruction sets are much more complex now, but I think people can get a good grasp just by looking at the 8080 instruction set, which and the 8080 was really the first processor that was really   went beyond what you would use for embedded systems. It was ready for prime time. So Absolutely.   Historically too, it was in the first what was considered to be the first   personal computer.  

[00:31:56] Unknown:

You mentioned some of the things that you felt needed to be addressed in the second edition, but I'm also interested in understanding   some of the decisions that you made in the first edition that succeeded your initial goal of not having to be revised and some of the ways that you thought about   as you're going through the 1st edition and now with the revision,   how to make this a book that does stand against the test of time and the massive pace of change in computing, and particularly now as we move into things like quantum computing and distributed computing. And  

[00:32:28] Unknown:

Yeah. The question I dread is how does quantum computing work? It's like   somebody else is gonna have to write that book. Some they have, but   not any that the common person can read, I think. Like I said, this book rattled around in my head for about 10 years, and it turned out that the first   10 chapters or so   were just fine,   and they needed a minimum of date. And these are the chapters where you're sending Morse code with flashlights and eventually using telegraphs and then showing how the relays work. There were some things, some chapters I switched around   for various reasons, but those worked fairly well. It was   when you really get to the precipice of showing how a CPU works.  

In the 1st edition, I did a complete cop out. In the 2nd edition, I said,   here we go.  

[00:33:22] Unknown:

In the   process of releasing the first edition, going through the work of revising it, releasing the second edition now,   what are some of the insights that you gained in terms of your own use and understanding of computers and software and how they interact as you went through the process of actually   detailing it in book form so that other people could understand it themselves?  

[00:33:45] Unknown:

You know, I thought that   designing hardware to implement the 8080   instruction set   would be a lot easier than it turned out to be.   That was that chip is more complex than I had thought.   Yeah. A lot of the instructions are very straightforward. They're in big groups of instructions, like these move instructions and add and and subtract and add it or instructions.   The circuits that I show is, like, my   reconceptualization   of how I would design it rather than, you know, I didn't go looking at the actual 8080 die and try to rip off how it was done there. It turned out to be a lot more complex than I thought. I was I had this idea that I could   show the hardware for implementing the entire 8080   instruction set, and it turns out   that was beyond.  

Maybe if I'd   spent another   year and added another 200 pages to the book, it could have been done.   But   nope. Nope.  

[00:34:51] Unknown:

And   the other interesting thing about any   book is that it serves as   a kind of common vocabulary, a common place for people to be able to read and have a shared understanding because they're all reading the same material.   So once somebody has finished with your book, I guess, twofold,   what are some of the   core ideas or lessons that you hope that they walk away with, and what are some of the other references and resources that you recommend that they move on to if they want to dig  

[00:35:25] Unknown:

understanding of what we're dealing with here from the transistors   up through high level languages.   For the first edition,   I accumulated   an enormous bibliography   of books that I consulted   to put this first edition together.   That bibliography   can still be found on my website   if people search far enough, deep enough. I'll give you a hint. It's if you go to my website, charlespetzel.com,   there's an about page, and there's a link to my old website.   And if you look at the code the book the page for the book code on my old website, there'll be a a link to the bibliography.   For the second edition,   a lot of that basic stuff had done that. And   I was able to   do the 2nd edition without buying any more research books. I did a lot of it just on Internet searches and getting stuff on Wikipedia.  

So   where a programmer where somebody   goes from here,   I don't know. I hope that people,   if they are   on their own trying to teach themselves some stuff,   I hope they start picking up some programming language. And, I mean, there's a lot of online resources   for learning programming these days.   When I decided I would need   to know more than just a little bit of JavaScript   beginning of 2021.   I thought I'd be buying a couple books   on HTML   5 Canvas.   Turns out, I did not need to do that, I'm sorry to say.   As someone who   wrote programming tutorials   for a living   and to experience firsthand the decline in sales as Internet resources   began to be more popular.  

I'm afraid to say that I myself,   I was a victim at the time, and now I'm doing the same thing myself.   I'm learning from online sources.  

[00:37:24] Unknown:

Are there any other aspects of the book itself, your work of putting it together and revising it, or the subject matter that it covers that we didn't discuss it that you'd like to cover before we close out the show? Over the years, people have asked, is there gonna be a second edition of Code?  

[00:37:39] Unknown:

And I've always asked, what would you like to see in a second edition?   And they would say something about the Internet.   And I was, oh, I don't know.   I did for this second edition. Right? The last chapter is about the Internet, but it doesn't go as deep as I think   the topic deserves.   What I hope   is that somebody   will   take a look at code and   see how   material can be introduced in a very friendly way and just build upon that, get further and further and deeper and deeper into the subject, and write a book that uses those basic techniques   about the Internet.  

I would love to see a book like that.   I picked up a book called something like How the Internet Really Works, and it, like, started off promisingly, but it didn't really go in that direction.   So I'm still waiting for that book, and   I'm not gonna write it. So I give anybody else permission to write that book.   I will read it. If you write that book and you get it published, let me know.   I'll read it. If I like it, I'll write a blog entry about it, and I'll say, this is great. If you write a great book, I'll say it's a great book.  

[00:38:53] Unknown:

Alright. Well, we'll see if after another decade of that idea kicking around in your head, you don't end up just writing it yourself.  

[00:39:00] Unknown:

Nope. You know you know, I'm   getting a little too old for this type of thing.  

[00:39:06] Unknown:

Fair enough.   Alright. Well, for anybody who wants to get in touch with you and follow along with the work you're doing, I'll have you add your preferred contact information to the show notes. And with that, I'll move us into the picks. This week, apropos of the topic at hand, I'm going to choose the movie The Imitation Game, which is   a possibly allegorical   biopic about Alan Turing and his work on the Enigma machine. And as the father of modern computing, it's definitely great to be able to at least get some understanding of his life and time. So definitely recommend that movie for anybody who is looking to be entertained for a couple of hours. And so with that, I'll pass it to you, Charles. Do you have any picks this week? This is entirely off the subject of computers, but yesterday, I picked up a brand new book called The, Confidence Man,  

[00:39:51] Unknown:

and it's by Maggie Haberman, who is a journalist for The New York Times. The subtitle is The Making of Donald Trump and the Breaking of America.   And she really I've only gotten about a 100 pages into it because it was only came out yesterday,   who eventually became president got his start in real estate.   So as we approach the midterm elections,   I hope everybody's gonna get out and vote.   I found that   I tend to think, often in very political terms, but I don't often write political blog entries. And I found it's much easier to write a political blog entry if I'm discussing a book.   So so far, I've I've discussed 2 books   about Trump's disastrous presidency, and I hope to discuss this 1 as well. And maybe persuade a few people how they should vote in the midterms.  



[00:40:44] Unknown:

Definitely appreciate you taking the time today to join me and share the work that you did on your book Code,   the work you did to revise it and update it for the   changing world of computing, and for taking the time today to join me and share your thoughts. So appreciate all of the time and energy you've put into your work, and I hope you enjoy the rest of your day. Oh, it's been a pleasure. Thank you so much.   Thank you for listening. Don't forget to check out our other shows, the Data Engineering Podcast, which covers the latest on modern data management, and the Machine Learning Podcast, which helps you go from idea to production with machine learning. Visit the site at pythonpodcast.com   to subscribe to the show, sign up for the mailing list, and read the show notes. And if you learned something or tried out a project from the show, then tell us about it. Email hosts@pythonpodcast.com with your story. And to help other people find the show, please leave a review on Apple Podcasts and tell your friends and coworkers.