字幕表 動画を再生する 英語字幕をプリント SPEAKER: This is CS50. DAVID MALAN: Hello, world. This is the CS50 Podcast. My name is David Malan, and I'm here again with his CS50's own Brian Yu. BRIAN YU: Hi, everyone. Good to be back again. So CS50 is taught primarily in C, is the programming language that we teach in the course at the very beginning. And a lot of students and people that we talk to very often ask, why C, why is that the programming language that you've chosen for CS50 as the language to start out with. And I know that a couple of years ago you answered a Quora post that was also asking the same question. But I thought I'd take today as an opportunity on the podcast to ask about that, push you a little bit on it, and just discuss that, the pros and cons of the programming language choice for this intro class. DAVID MALAN: Sure, in fact allow me to encourage folks to Google Quaro CS50 Why C, because, I daresay, it's a very thoughtful response out there that actually took a couple hours to compose. So I [INAUDIBLE] every point that I wanted us to hit. But it is a fair question. Honestly, this is one of those religious questions even that comes up all the time, especially when chatting with other teachers who teach computer science who might be using Python or Java or C++ or C or something else. It's kind of the go to language when you meet someone new in computer science to talk about languages. So here we are, another FAQ. So I think it's only fair to disclaim that some of it is probably my own upbringing when I took CS50 myself in 1996. Professor Brian Kernighan was teaching the class year at Harvard. And the course was under him and his predecessors primarily in C. In fact, even more of the course was spent in C. And so when I took the class, that was what I cut my own teeth on, so to speak. But with that said, with the benefit of hindsight, I do think pedagogically. I have a more thoughtful answer these days, having now taught CS50 itself and having deliberately chosen to stay with that language. I think that it just has so many pedagogically upsides despite some of its simultaneous pedagogically downsides. So it's a relatively small language. And even within a handful of weeks in CS50, can we expose students to most of the language. We leave out just a few more advanced or more arcane topics, like unions or function pointers, and a couple of other syntactic features as well. But by the end of the semester have students seen most of what constitutes C. Two, it's about as close to the hardware as you can get before you have to creep into what's called the assembly language, which if you think C is scary, assembly language is way scarier than that just syntactically and just how much control you, the programmer, have to exercise over what's going on inside the machine. That's a little too low level, I think, for students' first exposure to programming, whether they're a major or nonmajor. But I think it's also at the tail end of CS50, as time with C, it's just so wonderfully empowering to go on one day from-- or one week having implemented, say, your own hash table-- a particularly sophisticated data structure in C-- and probably having spent hours and hours getting that data structure to, not only be correct, but to be performant as well, using as efficiently as possible your computer CPU cycles and memory and then the next week, literally-- at least in the way CS50 is structured-- to go to Python, for instance, most recently or years ago in PHP, reimplementing the entirety of that data structure in just one line using a dictionary or dict in Python or using an associate of array in PHP. And I think that really speaks to the takeaways of abstraction that we want students to have in a course. You understand the underlying implementation details. But once you do, you can stipulate. I got that. Now I'm going to operate at and write code in a higher level of abstraction. BRIAN YU: So you talk a lot about the pedagogically upsides of C. What are the pedagogically downsides on the other hand? DAVID MALAN: Yeah, pointers is probably the go to answer here. With great power comes great responsibility. And admittedly, we do have to delve or we choose to delve deeply into pointers and memory management more generally, the upsides of which-- let me stipulate-- I think are that we can have even more interesting conversations about security and the implications for management of one's own data that you just can't have as effectively in higher level languages that protect you from yourself. But the downside, pedagogically and just technologically, is that students really do trip over their code ever more so because in C, if unfamiliar, you have the ability to actually touch specific addresses and memories. So if your program has the illusion of, say, 2 gigabytes of space, you can touch every byte of memory there, for better or for worse, even if you're not supposed to. And the result of touching memory that you're not supposed to is often what's called a seg fault or segmentation fault or, more mechanically, just your program freezes or crashes or behaves unpredictably in some way. And that is super, super common. But I think that it gives you thereafter so much more of an appreciation for what a computer or a language or a runtime is doing for you. Java's references become more of an aha moment. Oh, this is nice. I don't have to worry about this feature, this risk anymore. Python and other languages, Swift and Objective C, can do memory management for you. But you know what that means, and you know what's going on underneath the hood. And I just think that's a much better place to be in most any domain-- to understand the underlying plumbing at least at some point and then build on top of it even if you don't go into those weeds as much anymore. BRIAN YU: So just to play devil's advocate, a lot of what you do at the beginning of CS50 is first creating these abstractions and then diving beneath them later. You start by introducing like that string, we're just going to call it a string, before later in the third or fourth week of the course revealing, OK, here's what's actually happening in an underlying sense. And you might imagine that you could take the same approach with programming languages, introducing a higher level programming language like Python first and saying, well, here's the easy way to do it without having to worry about all the underlying details and then later on thing saying, let's now take a look at a language like C and figure out what's actually happening in Python when you're trying to run something like this. So how do you make these decisions about why do C first and then transition to Python as opposed to the other way around? DAVID MALAN: So one I should note that it's not so much I, it's we. So you're just as guilty as I am for teaching it this way. BRIAN YU: This is true. DAVID MALAN: Two, that would have been an amazing moment in a Law and Order episode, where on cross you get me to contradict myself like this. And that's actually a really thoughtful challenge. And I don't think in all the chats I've personally ever had about languages that someone framed it quite like that, to be honest. And for those listening, and this is not planned. I did not see this question in advance. So I think my pushback would be-- it's I think harder to justify, at least in the context of one course-- or it would be harder for me to justify in the context of one course-- going from a higher level, language like starting with Python, and then diving more deeply into C insofar as it probably doesn't really solve problems for students in the same way. Most of our students and most students, daresay, who are studying to become software engineers or who just want to apply programming in other domains, they're not going to have to bother with C and it's lower level optimizations and the performance that you can squeeze out of it. That's arguably, at least in the real world-- I daresay-- more of a specialized field or specialized use case for language where you really do want to be as close to the hardware as possible. And so I worry that that approach, that sequencing of things would invite more of a who cares or why are we doing this now. Whereas, if we can start from the older, the lower level language and just give ourselves enough training wheels early on that we don't have to trip over some of the harder language features like pointers and what a string actually is underneath the hood, we can peel those off but still be in that original language and then step from that level to the next. So I do concede that there's a bit of built in contradiction here. But to me it feels like the nicer balance-- start with the smaller, the more primitive language, layer on some training wheels, take them off. And then after taking those training wheels off, motivate a fundamentally different approach, different language altogether. That narrative just makes more sense to me. BRIAN YU: Yeah, and I can definitely sympathize with that.