DAVID MALAN: --it been doing so far is all that powerful,
when all we've been saying is, hello world.
And in fact, I hard coded the--
DOUG LLOYD: So there's a number of functions we have on the screen there,
and I will say from my own first experience with CS50
or in programming in C generally, one thing that's really annoying
is input output in C. It can be really difficult to get used to,
especially because in order to do it correctly
you usually have to use pointers which we don't want to talk about.
DAVID MALAN: Yeah, to allocate a buffer, or at least
allocate an array on the stack, and even then you're
vulnerable to buffer overflows.
DOUG LLOYD: Yeah.
No, this was something that we inherited from Eric Roberts from Stanford had put
together a library gen lib and [INAUDIBLE],
and he's ported those to other languages as well, that we--
Glen Holloway and I from CS50-- weaved into our own CS50 library where we
changed the documentation and the code itself a little bit,
but really just to give students some standard set of training wheels
at the start of the semester, really so that we can focus on getting input from
the user and not tripping over ourselves trying to explain why,
well you really need to give yourself an array first, and then put this--
it's just too much distraction.
DOUG LLOYD: Or getting mired in scanf and having
to have extra parameters to make sure that stuff doesn't get caught.
DAVID MALAN: Yeah, which scanf isn't bad for things like integers and whatnot,
but as soon as you start to have-- if the user types more characters then
you expect at the prompt and then hit enter, then it buffers up
and then you see it on the next request, and it just becomes a mess.
DOUG LLOYD: Yeah, I mean even having this discussion right now, if we
were having students see this early on it
could feel overwhelming talking scanfs and buffer overflows.
DAVID MALAN: Yeah, we're way ahead of ourselves now.
So these I think are compelling training wheels
in that we, again, consciously like almost everything in CS50
does take off eventually mid-semester when we context switch and really start
doing things at a slightly lower level, but I think early on they help us.
I think other languages suffer from this as well.
I mean even before Java had the scanner class,
and even now, there's a few lines of overheads to actually get
simple input from the user.
The big change we did make this year was fixing or changing to be more standard
our capitalization of these functions.
For nine years we used capital G capital S for get string and so forth,
and that was because those were the names of the functions
in the original libraries, but even--
I think Eric has since gone back in and changed
them to be a little more consistent snake case wise with C.
And we have ports of the library now to other languages where
we've made the naming scheme language specific, just
to preach best practices.
And indeed, that was thematic this whole year with CS50s videos,
to go back through and really do some spring cleaning,
remove material that had just gotten a little bloated,
but also make sure we were doing as many possible things rights,
or at least in the most standard way possible.
DOUG LLOYD: Teaching best practices as well as teaching concepts and skills.
DAVID MALAN: Exactly, so as to not accidentally send some wrong message.
Of course that meant having to redo every one of our resources, especially
the older videos, but that's OK.
I think we were staying current, and what better
time than when we're switching to version
2 of this new environment for us.
DOUG LLOYD: Now in addition to the functions that we use for I/O,
we also made a conscious effort to include some more of the debugging
functionality in the CS50 library this year
which allowed us to teach debugging concepts much earlier in the semester
then we've been able to do in the past.
DAVID MALAN: Indeed, and we don't have to care
about this at this point in the semester,
but now the CS50 library, thanks to some attributes that Clang, our compiler,
supports, does its own garbage collection or memory management
so that in years past when you would call, get string, every string you
would get back would be leaked essentially because you never actually
called free, unless we then later told students, by the,
way should really be calling free on your strings.
And that's really breaking the abstraction barrier
that an API is supposed to provide.
If you're giving me a string I should not have to do your cleanup for you,
I'd much rather the library in that case do it.
So the library now does that memory management for us, which is nice.
But it also has a eprintf in it too, which
we promoted this year as a function that's
pretty much just like printf, but for printing errors is eprintf.
And what it does is it's magically using some macro tricks in C,
is it prepends your line of output with the final name in the line number.
DOUG LLOYD: And also prevents the output from being buffered,
which can sometimes happen with printf, which
leads to red herrings about where exactly the error is coming up
in your program.
DAVID MALAN: For many years in office hours,
we would have students write some line of code--
And when trying to debug their code they will use printf to print something up,
but they might forget to include a trailing newline which
typically, as a side effect, flushes the standard out buffer.
And so the result would be that student's would
have some bug in their code or maybe get stuck in some loop,
but the thing they're trying to print here, even though you're
well past that point logically in your code, never got flushed,
and so you never see it.
And so they waste time and office hours for instance, or at home,
wrestling with a bug in the wrong place.
So now we just make every character print
the moment it's sent to standard out and a standard error.
DOUG LLOYD: Hopefully that helps to reduce the number-- certainly
at office hours this year we saw a lot less of that kind of thing.
DAVID MALAN: I think a good subtlety to understand eventually,
but not to not understand and get tripped up
by when you're really trying to focus on actually
solving some problem of your own.
DOUG LLOYD: Right.
DAVID MALAN: --whatever the user has typed in at his or her keyboard
in a variable called--
Notice, that's how I type.
DOUG LLOYD: Like that?
DAVID MALAN: Apparently that's what I think during lectures is typing. --two,
or three, or more, such that the second, or third, or--