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.
