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