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.
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.