Embedded - 496: Beauty, Elegance, Consistency

Episode Date: March 6, 2025

Professor Shimon Schocken spoke with us about teaching computer science from NAND logic gates to arithmetic units, micro assembly, virtual machines, compilers, operating systems, and the Tetris games. We also talk about good design, good interfaces, and good tests. Shimon’s book is Elements of Computing Systems and the website with the course lecture notes, slides, videos, simulators, and everything you need is nand2tetris.org.  Shimon mentioned his work with teaching math, that is www.matific.com. You can find out more about Shimon’s other projects on his site shimonschocken.com (including his fascinating TED talk: The self-organizing computer course). Shimon’s co-author is Noam Nisan who also wrote about understanding logic systems (look, anytime we can bring up Gödel's incompleteness theorems, we will). We talked about Tim Bell’s CS Unplugged, teaching computer science concepts without a computer. It comes in Classic and Modern flavors. Transcript Memfault is a leading embedded device observability platform that empowers teams to build better IoT products, faster. Its off-the-shelf solution is specifically designed for bandwidth-constrained devices, offering device performance and product analytics, debugging, and over-the-air capabilities. Trusted by leading brands such as Bose, Lyft, Logitech, Panasonic, and Augury, Memfault improves the reliability of devices across consumer electronics and mission-critical industries such as access control, point of sale, energy, and healthcare. To learn more, visit memfault.com.

Welcome to Embedded. I am Alicia White alongside Christopher White. What do NAND gates and Tetris have in common? Our guest this week is Shimon Shaken and he's going to tell us all about it. Hi Shimon, welcome. Hi, thank you. Thanks for having me here. Could you tell us about yourself? Yeah, well, I'm a computer scientist located in Israel. I am actually a computer science professor teaching at the university called the Reichman University. And I joined this university about 30 years ago and actually was one of the founders of this new school. Before that, I was a professor at NYU for 10 years.

Before that, I did a PhD at the University of Pennsylvania. I enjoy programming, hacking, building big systems, and I enjoy teaching. I think that the best way to describe my work is a computer science educator. That's me. You didn't mention writing a book called Elements of System Architecture. Right. Well, I think the correct title is Elements of Computing Systems, but it's essentially the same thing. Apologies. Yeah, well, you know, I did a few more things. Well, maybe I'll say a few more, some more details. I also, yeah, I wrote this book, which I guess we'll talk about.

And I also started up a company about 12 years ago that teaches elementary school mathematics using the computer games. And that's a very different aspect of education, but that's another passion that I have, teaching math using games. I mean, you also are teaching computer science using games. Yeah, actually, that's right. I also, you know, contrived all sorts of games to teach computer science, or actually more accurately algorithms. This is done in the spirit of a pretty large worldwide project called CS Unplugged.

It's a great project that started up in New Zealand from all places by a wonderful fellow named Tim Bell, a colleague of mine. And Tim and his colleagues put together a bunch of games. These are kind of schoolyard games and using very basic things like ropes and cards and balls and so on. And they teach, you know, all sorts of classical algorithms and data structures using these games. So the whole idea is to teach algorithms and sort of computational thinking without computers.

And because, you know, the irony is that, you know, once you have your hands on the keyboard, once you have a computer in front of you, you get distracted from the maker ideas. So, yeah, so that's another thing that I did. One way to make concepts more understandable is to give them physical form. Absolutely. Did that concept apply as you worked on the Nand to Tetris book?

Yeah, absolutely. You know, I'm not sure how deep you dived into the course that we provide a full-blown IDE that consists of a hardware simulator, a CPU emulator, a VM emulator, an assembler, and a few more tools. And it was very important to us when we wrote all these various simulators and emulators to visualize what happens, what's going on inside the computer. So for example, when we teach virtual machines

and we use the VM emulator, you can actually see the stack growing. When you, you know, when a certain command, when you do a push or a pop, you see the stack growing or shrinking. And the same holds for everything else that we do. When, you know, when you write a particular chip in a chipset, some of the chips have visualizations. So you can actually see a value going inside or into the register, and you can see the register kind of stabilizing on the right value before it outputs it and so on. So, yes, I think that visualization is terribly important in computer science education.

Elisio, you just said the book was Nantatetris. Is that the same book as Elements of Computing Systems? Yeah, well, you know, that's a bit of, I guess, confusion. The title of the book is The Elements of Computing Systems. And the subtitle is Building a Modern Computer from the Ground Up or from First Principles, I don't remember. And the course that we teach based on this book is called Nand to Tetris. Okay. Yeah. And I hear people refer to it as the Nand to Tetris book.

And they are right. Yeah, they're right. It's, you know, it's, and I'm not sure if the title is a good choice. I think, you know, some people find Nantotetris a little bit too whimsical. And so, in my university, the course is called Nantotetris. And not only in mine, in several other serious universities, so to speak, the course goes by this title. And yet some instructors, you know, feel better with a formal name like digital systems architecture or whatnot. And for these people, I think the title of the book is more appropriate. Also, there's a little twist in the title of the book because I called it the Elements of the Computer System because one of the greatest little books that I read is called

The Elements of Style. Ah, I wondered if there was a connection, yes. Yeah, by Strunk and White and I'm a great believer in style and so I hope that some people see the connection. So from the name of the Course, and I have not read the book, Elisa has read the book, and I am the ignorant observer. So the course takes you from gate level to building an entire computer capable of playing Tetris.

It's the basic idea, right? Yeah, playing Tetris and actually any other program. Okay. I mean, it goes from what is Boolean logic to how do you build these into parts of a processor, ALUs, and then it goes to how do you build microcode to run on those. And then assembly language. And then assembly language and a compiler and a small operating system and a display and then actual programs on top such as Tetris.

So I mean every single part. I don't understand how you could do this in a semester. So yes, how do you do that in a semester? Yeah, that's a good question. Well, first of all, you know, Noam and I, my co-author is Noam Nisan, who is a professor at the Hebrew University in Jerusalem. And, you know, it took us about five years

to put it together, but this was not, you was not full-time work. We were fully employed in other jobs when we did it. On and off, it took five years to get it right. The reason we can do it in one semester is that there are several reasons. First of all, we don't worry about so-called exceptions. So we assume that the input is always correct. And so when you write a compiler in our course,

you assume that the source code has no syntax errors. That seems like a really tough assumption. It would make me really appreciate a compiler that could tell me that I was doing things like forgetting a semicolon. I haven't had a compiler that can do that yet. You always get some other error. Well, you know, but you have to make these concessions for two reasons. First of all, you know, once again, if you want to write the compiler in two weeks or

three weeks, which is what we do, actually. And, you know, it's not only, you know, the course is taught in about 400 universities now. So, I'm speaking now for 400 other instructors, and who knows how many instructors will teach it outside the university system. So I'm speaking now for 400 other instructors, and who knows how many instructors will teach it outside the university system. So, and it works. The course actually works,

and students do build all the tools that I described. And so one trick is to assume that the inputs are error-free. And this actually has a great pedagogical virtue, because if you assume that you have to take care of errors, it can really distract you from all the great ideas of compilation, which is parsing and code generation. And I think that if I were to write an industrial strength compiler, I would do exactly the same thing.

I would start with a compiler that handles only valid code, and then I will add the error correction later on. I think it would be the right way to do it. That's one concession. The other concession is that we don't expect students to do any design in this course. Instead, we give them all the blueprints and the APIs. And so when they write a compiler, we tell them that we have a proposed implementation, which is based on the following API. And we break it down to the method slash function level.

So the compiler is actually a collection of something like 30, 40 different methods divided into something like four or five different classes or modules or files in Python. And by the way, we are completely language agnostic. You can write the compiler in any language you want. And so, you know, as long as it produces the right outputs, we are happy. So that's another concession, giving the students a good design, and I can elaborate on this later. And the third concession is not really a concession, but what should I call it? Third advice, I guess, is that, you know, I always think that before you write a program, you should first write another program that tests the program that you want to write.

And that's what we do here also. For every project in the course, we provide elaborate test scripts that describe exactly what the tool is supposed to do in an executable form. So yeah, and that's actually another feature. You know, for every tool that we want the students to write, we have an executable version of that tool. So the student can actually play with the tool and run all the tests on that tool before he or she wrote a single line of code.

And so they have to, they fully understand what the tool is supposed to do before they set out to actually build it. So that's another guideline. And there are a few more. And so, you know, all these guidelines are both, I think, both pedagogical and engineering, you know, know-how and sort of best practice. I think they go hand in hand. The second one, the no design. I noticed that your book separated the interfaces from the implementation very, very strictly. As you mentioned, you give people the interface, the API, and then they need to use the information they gathered in the chapter to implement to that API.

Is this how you want students to approach work in industry? Absolutely. I think that it's terribly important to separate obstruction from implementation on many different levels. Obstruction focuses on what the system is supposed to do. And implementation focuses on how the system should actually do it. And these are two very different perspectives

on the same thing. And I think that many catastrophic systems that I saw were developed because developers either didn't care or didn't know how to create this separation. And just imagine, writing code without fully thinking what you want the code to do. That's actually what happens when you don't separate. And when you forget about the implementation and focus only on the abstraction, you can basically, what you do is you manage complexity. You don't worry about numerous technical details and you focus about the big picture. And this will help you come up with a good modular design. This will help you come up with a good modular design.

This will help you come up with a design that lends itself to unit testing and when you do it right, you can also, as I said before, you can develop all your test programs before you write a single line of code in your system. Because what I'm saying now is probably widely done by good programmers. But once again, when you write a function or a method, it's best to just write the skeleton of the method and have it return zero or null or one or minus one or something silly like that, and then test it. Test the damn thing before you actually turn it into executable code.

And so when you work like that, you can focus on the architecture without worrying about the furniture and the interior design and so on. And this is another important principle that we try to convey in this course. The course is not really, well, I should be careful not to say it. I was going to say in the book that the course is not about developing a computer. It is about building a computer. But hopefully the take-home lessons are much broader. And one of them is the critical importance of separating obstruction from implementation. Do you worry that students will not understand how to do the design portion or the

unit test portion themselves, that they will get stuck into only the implementation portion? Yeah, you know, I do worry about it, but I think that they get it. I can elaborate about it a little bit, and also maybe with your permission I can sort of modify a little bit the question. One question that we are being asked every once in a while by colleagues is that, or I guess one possible source of criticism is that you don't really teach design. You know, you give all the designs to the students and they quote unquote only implement them. And that's true. This course is not about design. And yet it is about design. And I'll

tell you why. Because the best way to learn design is to see many good examples of good designs. And that's what we do. We give the students numerous examples of good designs. And that's what we do. We give the students numerous examples of what we think is good hardware design and good software design. And when the students implement them and they begin testing them,

they feel empowered. That's one word that we hear a lot from students in this course, we feel empowered. They feel empowered because the design sort of automatically guides them in the right direction. They write the code, they execute it, and boom, they realize that what they wrote sets the stage for the next function that they have to implement in a very natural way. And so they appreciate the designs that we give them.

And that's one bug that we have in computer science education. When you think about the course like Introduction to Computer Science, I think that in the first week, second week of the course, the students begin to write programs and they don't really read programs. They only write, write, write, write, write. And when you think about Introduction to Poetry instead of Introduction to Computer Science, I don't think that the Po't think that the literature professor comes into the class in Introduction to Poetry 101 and says, for the next lecture I want you to write a poem. Instead, she will say, here are four great poems, read them.

Or read them and tell me how you feel about them. We don't do it in computer science. What we could do is come into the class and say, here are four programs. Two of them are great. Two of them suck. Why don't you tell me what you think about each one of these programs? That's something, once again, that we should improve in computer science education and in programming education in general. And that's another reason why we gave all these designs because we wanted to show examples of good designs, learning

by example. That's an interesting point about reading because when we were in undergraduate, the open source movement didn't, wasn't really, it was just getting off the ground. And so there weren't a lot of great examples publicly available of good code. We went to school before Wikipedia and way before GitHub. Right. So it would have been much more of a challenge to find a lot of examples of good code that were publicly open and available. Whereas now, there's tons of it everywhere.

Go check out the Adafruit sensor library. Right. Yeah. Just a good example. Yes, I love this idea of teaching people to read code. And I totally agree with you about the book, that it actually encouraged me as I was reading, I was thinking, how will we implement this? And then we got to, then I got to your implementation section with the API, and the way you had broken it made a lot of sense and the parts where

I was going to go somewhere different, it made me question my assumptions. So it was great. I mean, yes, you don't teach design the way some people teach design. Instead you give really good examples. And I mean, if this was a live stream, I would have put so many little hearts there to indicate how much I agree with you. Right. I'm glad to hear that.

By the way, the designs are optional. If a student comes up with her own design, that's perfectly okay. You know, once again, in this, because we do everything in one semester, we don't have too much time to, to comment about, well, shouldn't get into all the details of grading and all that. But basically, you want,

you know, when you write a compiler, we want to see our compiler working. And if you chose a different architecture, that's fine with us. Although I must say that in 99% of the cases, the students simply follow our own design. So it's not mandatory, but it's highly followed. Thank you to Memvault for sponsoring this show. We appreciate their sponsorship and the work that they do. Memvault is a leading embedded device observability platform that empowers teams to build better IoT products faster.

What that means is that if you have just realized that you're going to build five, ten, a hundred, fifty thousand units and you need to keep track of them, they'll let you create your own dashboard to observe how your system is doing in the field. MemFault gives developers a more scalable and sustainable process. This accelerates the time to market and de-risks product launches. You can cut product costs and deliver more high-quality software. Trusted by leading brands such as Bose, Lyft, Logitech, Panasonic, and Augury, Memfault improves the reliability of devices across consumer electronics and across mission-critical

systems such as access control, point of sale, energy, and healthcare. Thanks again to MemFault for sponsoring this show. Check out MemFault.com and the interrupt blog, which is filled with incredible amounts of information. I did think a semester was short for this pure amount of information, partially because I don't think

I could have learned all of the details of logic from this course. If I had taken a different course that taught all of the circuit logic things, then this would have been a good refresher, but I don't know that I could have gone from zero to ready to use it in a short time. I kind of wanted this to be a year-long course, but that would have just been me playing professor. How did you decide what pieces of information you had to assume the student would know. Okay, we assume knowledge equivalent to introduction of computer science, and some, which you know a corollary of this is some good programming experience, typically in a language like Java or Python. We assume basic knowledge of object oriented, but not too much. We don't really need inheritance and we just need to understand what are objects and classes and so on. Because some of our designs are object oriented.

And we assume in a typical university setting that at some point the student will take many other super relevant courses, like logic design, like operating systems, like maybe compilation, like advanced programming. But we don't necessarily assume that they took them already. necessarily assume that they took them already. When they take these courses, they kind of, every once in a while, they smile to themselves and say, gee, we did that in Antutetris, and we did it all the way, and we saw how it interacted with concepts from other courses that we took. And that's a very important feature of this course. It connects ideas from many different courses in a sort of hands-on fashion. But also, I have to take acceptance to one thing that you said about needing logic. You're right, when you implement something like XOR,

you have to know something about, you know, the XOR logic. And yet we explain some of it in the course and we expect students to, you know, they can go to the internet and find out how XOR is implemented. We don't care. And, you know, once you know the basic logic formulas, then you have the challenge of actually implementing them in HDL, which is kind of a functional language, or with our own version

of HDL, which is something that you can learn in one hour. So the logic knowledge is we either assume that the student gets it somewhere or in many cases we give it away. We just, you know, in the lecture or in the book, I don't remember exactly where, we tell them, you know, we can implement, you know, an adder chip, a chip that adds two bits. You can implement it using end and XOR. And, you know, the sum can be implemented using an end gate and the carry bit can be implemented using XOR, the other way around, I don't remember. And so we give them many hints about how to do it. And then, you know, you have to set out and do it. And likewise, when we implement, let's say, a RAM device,

then we tell them something like, the RAM, let's start with a RAM of eight registers, and an input value comes in. We recommend that you feed this input to all the registers simultaneously and then take the address input and use it to select which register to open, so to speak, to load, to set the load bit on which register, and one register should have an asserted load bit and all the others should have their load bits set to zero. Once you gave this hint in one way or another, the logic part or the logic challenge goes

away. You don't have to worry too much about understanding the logic, but you still, once again, you have to actually implement it. So because of that, there's a very interesting phenomenon in Nantotetris, something that we never anticipated. It turns out that the first part of the course, which is building the hardware platform, can be done by any student or any learner without any previous knowledge. And you don't need programming to do it, because the only thing that you need to know is HDL, and we teach you HDL in the course, our own HDL. So actually, the first part of Nandu Tetris,

building the hardware platform, is something which is widely done in high schools and in various programs, community programs and so on. And that's the typical kind of journey that students take, is that they do the first half of the course somewhere, they get completely hooked on the approach, and then they go on to do the second part of the course, which is actually much harder, you know, developing the software hierarchy. I guess I spent so much time with De Morgan's law and trying to optimize exactly how to put the

logic together for the minimum number of operations. And I still have that part of my brain that says, this was harder than I expected. But if you don't try to go for the minimum number of operations, it's not nearly as fun, but it's also not nearly as challenging. I think that's why I kind of had it as a, wow, this doesn't seem like enough. But I seek your point. But you were self-paced.

If you were forced to move on because of the pace of the course, would you have spent so much time on that? No, the whole De Morgan's Law was many years ago. So it was- Oh, I see. Not while you were doing this. Not while I was doing this. This I actually could rush through that because I had already spent- Got it.

Plenty of pain on exactly how to do these. Yeah, well, let me comment about this. Two comments. First of all, another concession that we do in this course is that we don't care about efficiency. Yeah. And that's a huge concession because 90% of computer science is about efficiency and we don't care about it.

So if you write your chip using 10 chip parts instead of seven, that's perfectly okay with us. You know, if it's 10 instead of one or two, maybe a problem. And so that's another huge concession, which the students appreciate. And the second comment is that coming up with a minimum number of gates, well, I have to tell you, it's an NP-complete problem. So don't feel incompetent or something. That's how you should feel. It's a huge combinatorial challenge and it's very difficult to optimize these

chips. There are some tools, if you remember the term, something called Carnot maps and all sorts of theoretical and practical tools that help you sometimes come up with better design, but the general problem of coming up with a minimal design is unsolvable. It's a huge open question. So definitely we don't deal with it in this course. And one of the things that I see with students coming out of college is that some of them are very focused on trying to get the most efficient, most optimized system, and yet we don't actually need to do that very often. I mean, yes, sometimes there's one loop that needs to be optimized, but I don't want to optimize all the code if there's only one area of concern.

And so I like that you're not dating on efficiency because we don't always need it. Our processors are getting bigger and faster. Definitely. Yeah. Well, let me maybe say it a little bit differently. I think that I prefer readability on efficiency. So in the course, the course gives you a great platform to come up with all these insights and share them with the students. Once again, I think it's another reason why the course became popular is because different

instructors use it to emphasize different lessons. So in that respect, it's kind of open-ended. When you say the course, you have the book, which anyone can purchase, and you have a website and a GitHub repo with all the simulators and code, and you have slides, and you have an online project simulator. And can anyone just use this for their own class? All of that? Yeah, yeah.

So that's, there are many courses out there that students can take freely in open source. The special thing about our course is that you can also teach it freely. So anyone who wants to teach this course can simply go to the website, take whatever he or she wants. And if you want more material, you can send me an email and send you some more stuff. And so, yeah, so the course is widely available. It's a lot of work for you to make just freely available. Yeah, but, you know, I'll say something that sounds maybe a bit ideological, but I think

both Noam and I, Noam, my co-author and friend, we feel very fortunate. We feel grateful to the universities in which we studied and to the universities in which we taught. We feel that they gave us a lot. When I say they, I mean the teachers that taught us, the institutions in general, and we view it as an opportunity to give back. So that's where we made everything widely available. I have a couple of listener questions and one of them is really relevant.

Are you aware of any institutions in Africa that use the NAND to Tetris in their curriculum? From Antoine. I'm afraid not. I mean, I'm not aware. Yeah, actually, I do remember getting emails, I think, from Nigeria. I get numerous emails from people who either take the course or teach it. And there were over the years quite a few emails, maybe a dozen emails or so from people from Africa, but I don't remember if they took the course or taught it. So it's quite possible that they took it in Coursera or something like this, and I don't know if this counts. So I don't know. I can tell you, you know, I mentioned the math games program. So this program is being used in Africa. It works in Swahili. And so it's taken in

So it's taken in several different countries in Africa. And it's also free. I mean, the African version is free. And there's no reason why an institution would have to tell you it was using it. That's right. So when I said that it's being taught in 400 universities, these are universities that I know about. In other words, instructors who sent me an email saying, I'm teaching this course in this and that university and can you send me some more material?

So I have 400 of those and it's quite possible that there are many others who teach it also. The next question is from Benny. Do you have an extension to this program, and what is it? Yeah, well, we don't have an extension. You mean kind of a follow-up course? He actually said embedded extension, so I do think that is a follow-up course. Yes.

Well, the embedded extension is not really a follow-up course. It's a project. It's an optional project in which you can basically implement the computer in FPGA. And there's a whole project that sort of guides you through doing that. So you have to buy $50 a board from somewhere. And so we give some recommendations where to get it.

And then we guide you through the process of actually taking our HDL, porting it into industrial strength HDL like Verilog and then or VHDL and then putting you know this code into the FPGA and this was actually done by a student that took the course. His name is Michael Schroeder from Germany and he did it very nicely and now I work together with him to make it more accessible to other students. But it's already in the website. So if you go to the website there's a section called Cool Stuff and one of the projects in the cool stuff is the FPGA implementation. Benny also asks if you were to develop a new course from scratch, what would it be?

So both Noam and I did follow-up projects which are somewhat in the same spirit and different levels of maturity. So Noam, together with another colleague, his name is Yanai Goncharovsky, so Noam and Yanai have built a course and wrote a book. I think it came out in Cambridge University Press. They basically, I know what they say sounds a bit crazy, they implemented symbolic logic. And basically, they start with the most basic concepts in logic. What is an alphabet of symbols? What is an axiom?

What is a proposition? What is a conjecture? What is a theorem? What is a truth table? And every one of these concepts is implemented in a little Python program that typically consists of something like three or few lines of code. And as you go from one week to another, you basically build logic from the ground up. And after working for once again a whole semester, you end up with what is known as Gödel's Completeness Theorem.

And you actually prove Gödel's theorem, but you prove it constructively by actually building everything from the ground up. Didn't Gödel's Completeness Theorem say you couldn't do that? No, that's several theorems. The first completeness theorem says that in what is not a first order logic, you can do it. In other words, basically the theorem says that everything which is true can be proved, right? And so, if you limit yourself to propositional logic, which is logic without variables, only basic logical

arguments, then it's complete. If you move on to predicate logic, in which you can use quantifiers like for each and for all, then you get stuck. Then there are true things that you cannot prove. So the first theorem, which is very important, just like the other ones, is kind of the pinnacle of Noam's second course. I shouldn't say second, it's a different course, but it's exactly in the sense spirit of building everything from the ground up. That sounds fun.

Yeah, it is. And you know, this course replaces the traditional course in mathematical logic, which students are really traumatized. I love that course. Oh, that was a weirdo though. You know, because there's so many syntax issues and language that describes a language that describes a language and so on. And in Norm's course, in Norm and Genai's course, you actually build everything.

You build everything in Python. So the students, you know, they don't feel that they study logic. They end up studying logic very well, but they study logic by writing numerous little programs and proving everything, you know, along the way in the way of construction. They don't prove theorems, they just build code and the code works and that's a proof that it works. So it's not highly formal, but it turns very challenging course both for teachers and students to something which is completely

fun. And so that's what Noam did. And what I want to do, and I started can call it whimsically from Nend to life. Basically what we want to do is build things proteins, step by step. So start with the basic, you know, DNA alphabet and from the DNA build genes and chromosomes and using genetic code, build proteins and then maybe even from the proteins build some organs and end up

with a cell, some functioning cell. And everything obviously is terribly reduced with great simplifications. But the basic ideas hold. We want the students to visualize everything and to feel that they build stuff along the way. And once you go through this course, you'll understand, I hope, the basic ideas in molecular biology without numerous details, of course. But that's work in progress.

It's not something that I can really talk about too much because we just started working on it. The idea of a streamlined synthesis course for big disciplines is actually applicable all over the place. Yes. And that's a great comment. I agree and a great insight. And it's an important insight because it's really done,

which I think is rather crazy. You know, computer science is very much a top-down discipline. When you think about the program, the first course in the program teaches you something like Java or Python. And so you end up taking introduction to computer science and you know nothing about computers. Programming, you can solve some problems,

but you have no idea. As far as you're concerned, a computer can be a coffee machine. That's the price, so to speak, of top-down design, that you don't understand the machines that make your ideas actually execute. Our approach is bottom-up. That's why the subtitle of the course is Building a Modern Computer from First Principles. So in our approach, you start with the most basic things, and it may take two or three weeks before you understand

why you started with these particular building blocks, which I think is great for, you know, it has a great educational virtue because we live in an era where instant ratification is king, and I think that this is terrible for good rigorous education. So the fact that the student is left a little bit in the dark for a while, and then at some point the students say, wow, I now understand why I had to use these particular building blocks. It makes perfect sense to me. I think it's great.

I think it's a great experience to withhold these aha moments to a later stage where, you know, where you put a lot of work and you feel accomplished and empowered and all of a sudden, you know, things fall into place. I think that, you know, if you think back at your education, you will remember these great moments where all of a sudden things begin to click. And this is something that happens when you do bottom up because system building, it takes a little while before the puzzle

begins to take shape. I think that's interesting you said about our education because listeners are going to get tired of me talking about this. But when I learned computers, I was a very young kid and I had an Apple II plus in the late 70s, early 80s. And it was a very simple computer by modern standards. It's a very simple computer by toaster standards now. But, you know, when you got one of those, there was not a lot of hand holding. It had a basic interpreter. It had a ROM monitor and assembly language and a whole ream of manuals with all of...

That included schematics. And the ROM does disassemble. And so people, hobbyists and people, I think even in school, were learning computers with very simple systems that you could comprehend after a short period of time. And now computers are so complex that... They're magic boxes. They're magic boxes and people are going through school and learning, oh, well, I'm going to write, you know, I don't know, Node.js that runs on AWS to handle backend requests and things which is so divorced from the bottom part of computers, right, that it's almost like a different system.

And I think getting back to the, okay, this is how these work. All of them still work this way. There's just more of this. It's really, really helpful because it's better to have people who understand what's going on than people who are skimming the surface and can, you know, do a very narrow set of things. I don't really know what my point was, but. No, no, Chris, I think I completely connect to what you just said.

And actually, I opened the book, which I have in front of me, and I'm going to read to you the second paragraph of the first page in the book. And the second paragraph says, in the early days of computers, any curious person who cared to do so could gain a gestalt understanding of how the machine works. The interaction between hardware and software was simple and transparent enough to produce a coherent picture of the computer's operations. Alas, as digital technologies have become increasingly more complex, this clarity is all but lost. The most fundamental ideas and techniques in computer science, the very essence of the field,

are now hidden under many layers of obscure interfaces and proprietary implementations. And so on. So that's exactly what you describe. Perfect. One of the things you mentioned was trying to build this, I want to call them information gaps because that's how it was introduced to me. But these little parts where people don't quite understand and they get curious and it drives them to feel this need to get the next piece of information.

It creates curiosity. How do you build courses that have those? Is that the bottom-up part of teaching or is that something else? I don't claim that they have a recipe for building any course out there. I think one thing that Noam and I contributed in the field of computer science education is exactly that point, that you can teach system building bottom-up quite effectively.

And yet, I think that top-down is also very important. So the answer is that you need both. You need students to understand both top-down design and bottom-up design. But before Nandu Tetris, everything was thought almost exclusively top-down. And so one thing that we do, well first of all there is, students understand, and that's the contract, they understand that at the end of the game, they'll have a fully functioning general purpose computer that they built. So they see the goal. They see it, this is kind of the holy grail,

and they know that they'll get to it because senior students tell them, don't worry, you'll get to it. Those students who did it already before them or students who took it in Coursera and so on. So you know that you're going to get to the promised land. That's very important. You have this belief that it's going to happen. And then we give them, we task them to build something, and they don't really understand why they do it. Let me give you an example.

The VM language. The VM language is kind of a stack machine language. You don't understand why you need push and pop and why you implement add in this crazy way of popping two arguments, computing the sum and pushing it back into the stack. Why do you need all this? You don't know. By the way, you will know exactly why you need it when you write the compiler, because the compiler generates VM code.

When you see your Java code being translated into the VM code, the VM language that you implemented two weeks ago, then you say, gee, wow. The fact that they have a VM language really allowed me to write a very elegant compiler because I don't have to go all the way to generating assembly code, which would have been a nightmare. And instead I can take a Java operation like 5 plus 3 and generate code that says push 5, push 3, add. And so I appreciate the beauty of doing this

and why I had to work hard on building the VM language before. So knowing ahead of time that you're doing something which is very productive and that leads you in the right direction I think is psychologically important. And the other reason And the other reason why I think students are engaged is because there is something that you can call the... I think that everything that you do in science and engineering has both...if it's well done, it has both, I call it internal validity and external validity. The external validity is the fact that it has some practice, some purpose in the world. It serves a purpose.

You don't just build it as an intellectual exercise. You build it because it's needed somewhere. So that's external validity. No less important is internal validity. Internal validity is more elusive and it has to do with beauty, elegance, consistency, fun, and so on. So when we teach the VM language,

we tell the students, look, you're implementing a machine. It's not completely clear yet why we need it, but it's a very nice machine. Now it has all these little operations, which are very elegant and have this once again internal consistency and beauty and elegance and the students appreciate it, I think. And so that's another way to motivate things, to argue and to show that they are simply fun to play with. I have to say, I really enjoyed the book. I wasn't exactly the target audience, given that I'm pretty far out of school at this point. But it was beautiful to see all of these things put together in a way that I mean, I did some of the projects

because it was engaging. And I admit I did not do the operating system one because it felt too close to what I was working on at work. But I really enjoyed your project, your book and the course. And I guess I should also shout out to Nathan who I think introduced me to it. He noted that the authors, you and Norm, did a great job of taking the equivalent of four to eight college courses and fitting them in 12 book chapters. Nathan almost feels like the book should be required reading for any computer scientist, embedded systems engineer, really anyone who works with processors of any size. And I totally agree with that. Now, I have a whole bunch of questions about proteins and how much hydrophobicity matters

in your program because I think you need that in order to create membranes. And Christopher is looking at me like I have lost the plot of this show. Do you have any thoughts you'd like to leave us with, Shimon? I guess it sounds very old school and old fashioned and conservative, but I believe in hard work. And I think that if you want to know something deeply, you have to work hard to get to the depth of it. And there are many good courses and many good resources out there that help you to do that.

But don't expect shortcuts because if something is easy to learn and then you don't really distinguish yourself in any way. Anyone can learn it, so what's in it for you? Yet if you're willing to commit yourself to working hard and once again getting to the bottom of a great idea, of a great piece or a great piece of engineering, then you will gain a lot. You will gain, you will feel much more empowered and accomplished and it will boost your self-confidence.

And so don't be afraid from hard work. Hard work is good. That's one advice that I can think of right now. Our guest has been Shimon Shaken, professor at Reichman University and founding dean of the IFA Arazi School of Computer Science. Check out NAND2Tetris.org, that's N-A-N-D, 2 as in the number, and Tetris.org. You'll find the simulator and the book, and of course, we'll have lots of links in the show notes. Thanks, Jermone. Thank you.

Thank you to Christopher for producing and co-hosting. Thank you to our Patreon listener Slack group for their many questions, which I did not get to. Thank you to Benny for the recommendation and Uri for the introduction. And thank you to our show sponsor MemFault. You can always contact us at show at embedded.fm or hit the contact link on embeddedfm. Now a quote to leave you with from Uri Pasteur. Let me tell you the secret that has led me to my goals. My strength lies solely in my tenacity.