00:00:00,690 --> 00:00:05,040 DAVID MALAN: --between two persons, A and B. So before we transition to that new world. DOUG LLOYD: So I see on the table there just a second ago the cousin of our friend here watching the video with us. DAVID MALAN: Yeah, well this is our duck debugger. DDB50, perhaps one of the most clever we've ever done. 00:00:20,675 --> 00:00:22,800 DOUG LLOYD: And what exactly is this duck here for? DAVID MALAN: So, turns out rubber duck debugging is kind of a thing, such that some people in the absence of other humans to talk to, will pick some inanimate object, and somehow it became a rubber duck because the duck will not judge you, it will not criticize you, you can talk to the duck and explain to the duck, or really anything or anyone, what you think or what you hope your code is actually doing. And it's really meant to be not just a catharsis, but also an opportunity to hear yourself talking through your own code at which point, hopefully you have your own self-induced aha moment when you realize your code actually doesn't do what you are saying it's supposed to do or vice versa, you realize that you're describing it incorrectly all together. DOUG LLOYD: Right, because the duck's not going to nod its head and say, OK, yeah, I get what you're talking about. You have to actually pick every line. DAVID MALAN: Yeah, so we've gotten a non-zero number of reports of CS50 students who now have these in their dorm rooms saying that they're debugging their code by way of talking it through to a duck. And you know, it's funny, it's a silly thing and it was really just a way of coming up with an excuse for having what is an eight-foot duck on the screen in this lecture, eventually, that AJ kindly snuck onto the stage, or [? Colten, ?] but it's kind of true. I've actually found and been frustrated by myself when I've been wrestling with some bug or some design of some computer program, not just for CS50 per se, but more generally, and then finally a colleague walks by and say, hey can I bounce some ideas off of. And it's just so incredibly helpful and revealing to actually talks through something with someone else. I mean I'm actually feeling this way right now with this. I'm really understanding now what CS50 explained is all about. But you hear yourself speak and it gives you a chance to kind of clean up what you're saying, because while it might be all messy in your head, you have to verbalize it and clean it up at which point you find the faults. DOUG LLOYD: Right, but this is not the only debugging strategy that we have. We have the in-person debugging strategy, but we also decided to tackle the debugging problem, which is a longstanding problem of how to teach debugging and how to do it effectively, with the Debug50, the improving of our graphical debugger from 2015. DAVID MALAN: Thanks to Dan [INAUDIBLE], [? Karim, ?] who have contributed so much now to the CS50 inspired graphical debugger that's built on top of Cloud9, but is GDB specific. The GNU debugger that we've long used in CS50, operated in a command line environment. It's nice. I mean GDB is an incredibly powerful tool, but so hard to use for so many people, in part just because-- DOUG LLOYD: And hard to teach. DAVID MALAN: Hard to teach, and in part just because it comingles its output with the program's output and the commands themselves are pretty arcane, you don't necessarily just see data constantly, you have to type the commands with which to see that data, and just a lot of steps get in the way, a lot of mechanics get in the way of the debugging ideas. And so it's nice. I mean in CS50 IDE now, thanks to the debugger, you can just constantly see the current stack frames and the current state of your stack. You can see all the local variables, you can set breakpoints and step through it, and so it allows you to focus on exactly the same ideas of debugging, but without the textual or syntactic distractions, much like the reasoning behind our use of Scratch initially before we switch to C. DOUG LLOYD: Right. We definitely saw a lot of this at office hours this year. Students really getting right into the weeds of debugging and getting their handle on Debug50, but there was one other tool that we consciously spent a lot of time working on this summer in particular. Brian, you, and Annie Chen who spearheaded the effort for Help50, to help make better sense of-- DAVID MALAN: That was amazing, you said Help50 the moment I said Help50. DOUG LLOYD: What can I say, I'm pretty good at this stuff. But it gives us an opportunity to really pick apart some of those really arcane error messages, like clang is kind of notorious for being very difficult to sometimes parse. DAVID MALAN: Certainly early on when you're new to it all, especially if you've got one bug that triggers a cascade of other bugs, and so you're overwhelmed with the number of error messages on the screen. And you know, I wish we had thought of this earlier, because at the end of the day Help50 is super simple. It really is just several dozen regular expressions that Brian, and Annie, and others wrote, they just look at a student's output and try to pattern match, looking for things that might be arcane but at least are deterministic and you can infer from them what the problem might be and offer some rhetorical advice. So it's really meant to be like our virtual TF. That isn't wrong, too. I mean we've tried to word all of it's help output in such a way that we don't tell a student what to do, we ask them and prompt them with questions to help-- DOUG LLOYD: The same kind of questions that you would actually propose-- DAVID MALAN: --them figure out-- DOUG LLOYD: --in office hours if we saw this happening. DAVID MALAN: Exactly. Exactly. And this has been an interesting tension and I think discussion that Glen [? Holloway ?] and I've had for some time, because I've long had a tendency to try to simplify things in student's environment, the IDE back in the cloud days, the appliance, but we haven't wanted to have a Clang50 command or Make50 or wrapper scripts that could absolutely exist, but then really put too much in the way of training wheels on students, because in the real world they're not going to have Make50 and Clang50 and so forth. They're going to have make and clang, and we want them to use those standard tools. But Help50 is really meant to be temporary training wheels, a throw away, that after a few weeks of familiarity and usage, then they can discard that and move on and we've not sort of done them a lifelong disservice by teaching them some tool in the wrong way. It's just a tool dedicated to that. DOUG LLOYD: It was a lot of fun, and a lot of the staff got involved in helping to improve this tool. And I think it was one of the most helpful contributions we made in the debugging context for students this year. DAVID MALAN: Indeed. So I mean we have Debug50 now, Help50 now, eprintf now as well for more homegrown debugging, but all of which provide a pretty good tool chain. You know, a fun fact, these things kind of squeak a little bit, and I've on multiple occasions been in faculty meetings this year where I brought a CS50 duck in my jacket pocket with the intent of giving it to a colleague as a little, hello from CS50 and invariably in two of these meetings it's sitting there in my pocket, very discreetly, no one knows that I've got a rubber duck hidden in my jacket, and then invariably I'll just move or something and I move my arm against my side and it's like, who the hell has a rubber duck in the room.