SPEAKER: This is CS50.
DAVID MALAN: Hello, world.
This is the CS50 Podcast.
My name is David Malan, and I'm here again with his CS50's own Brian Yu.
BRIAN YU: Hi, everyone.
Good to be back again.
So CS50 is taught primarily in C, is the programming language that we teach
in the course at the very beginning.
And a lot of students and people that we talk
to very often ask, why C, why is that the programming language
that you've chosen for CS50 as the language to start out with.
And I know that a couple of years ago you
answered a Quora post that was also asking the same question.
But I thought I'd take today as an opportunity on the podcast
to ask about that, push you a little bit on it,
and just discuss that, the pros and cons of the programming language
choice for this intro class.
DAVID MALAN: Sure, in fact allow me to encourage folks to Google Quaro CS50
Why C, because, I daresay, it's a very thoughtful response out there
that actually took a couple hours to compose.
So I [INAUDIBLE] every point that I wanted us to hit.
But it is a fair question.
Honestly, this is one of those religious questions even that comes up all
the time, especially when chatting with other teachers who teach computer
science who might be using Python or Java or C++ or C or something else.
It's kind of the go to language when you meet someone new in computer science
to talk about languages.
So here we are, another FAQ.
So I think it's only fair to disclaim that some of it
is probably my own upbringing when I took CS50 myself in 1996.
Professor Brian Kernighan was teaching the class year at Harvard.
And the course was under him and his predecessors
primarily in C. In fact, even more of the course was spent in C.
And so when I took the class, that was what I cut my own teeth on,
so to speak.
But with that said, with the benefit of hindsight, I do think pedagogically.
I have a more thoughtful answer these days, having now taught CS50 itself
and having deliberately chosen to stay with that language.
I think that it just has so many pedagogically upsides
despite some of its simultaneous pedagogically downsides.
So it's a relatively small language.
And even within a handful of weeks in CS50,
can we expose students to most of the language.
We leave out just a few more advanced or more arcane
topics, like unions or function pointers,
and a couple of other syntactic features as well.
But by the end of the semester have students seen most of what
constitutes C.
Two, it's about as close to the hardware as you
can get before you have to creep into what's called the assembly
language, which if you think C is scary, assembly language is
way scarier than that just syntactically and just how much control you,
the programmer, have to exercise over what's going on inside the machine.
That's a little too low level, I think, for students' first exposure
to programming, whether they're a major or nonmajor.
But I think it's also at the tail end of CS50, as time with C,
it's just so wonderfully empowering to go on one day from-- or one week
having implemented, say, your own hash table-- a particularly
sophisticated data structure in C-- and probably having spent hours
and hours getting that data structure to, not only be correct,
but to be performant as well, using as efficiently as possible
your computer CPU cycles and memory and then
the next week, literally-- at least in the way CS50
is structured-- to go to Python, for instance, most recently
or years ago in PHP,
reimplementing the entirety of that data structure
in just one line using a dictionary or dict in Python
or using an associate of array in PHP.
And I think that really speaks to the takeaways of abstraction
that we want students to have in a course.
You understand the underlying implementation details.
But once you do, you can stipulate.
I got that.
Now I'm going to operate at and write code in a higher level of abstraction.
BRIAN YU: So you talk a lot about the pedagogically upsides of C.
What are the pedagogically downsides on the other hand?
DAVID MALAN: Yeah, pointers is probably the go to answer here.
With great power comes great responsibility.
And admittedly, we do have to delve or we choose to delve deeply into pointers
and memory management more generally, the upsides of which--
let me stipulate--
I think are that we can have even more interesting conversations
about security and the implications for management of one's own data
that you just can't have as effectively in higher level languages that
protect you from yourself.
But the downside, pedagogically and just technologically,
is that students really do trip over their code
ever more so because in C, if unfamiliar,
you have the ability to actually touch specific addresses and memories.
So if your program has the illusion of, say, 2 gigabytes of space,
you can touch every byte of memory there,
for better or for worse, even if you're not supposed to.
And the result of touching memory that you're not supposed to
is often what's called a seg fault or segmentation
fault or, more mechanically, just your program freezes or crashes
or behaves unpredictably in some way.
And that is super, super common.
But I think that it gives you thereafter so much more
of an appreciation for what a computer or a language or a runtime
is doing for you.
Java's references become more of an aha moment.
Oh, this is nice.
I don't have to worry about this feature, this risk anymore.
Python and other languages, Swift and Objective C,
can do memory management for you.
But you know what that means, and you know
what's going on underneath the hood.
And I just think that's a much better place to be in most any domain--
to understand the underlying plumbing at least at some point
and then build on top of it even if you don't go into those weeds as much
anymore.
BRIAN YU: So just to play devil's advocate,
a lot of what you do at the beginning of CS50
is first creating these abstractions and then diving beneath them later.
You start by introducing like that string,
we're just going to call it a string, before later
in the third or fourth week of the course revealing, OK, here's
what's actually happening in an underlying sense.
And you might imagine that you could take the same approach with programming
languages, introducing a higher level programming language like Python
first and saying, well, here's the easy way
to do it without having to worry about all the underlying details
and then later on thing saying, let's now take a look at a language like C
and figure out what's actually happening in Python
when you're trying to run something like this.
So how do you make these decisions about why
do C first and then transition to Python as opposed to the other way around?
DAVID MALAN: So one I should note that it's not so much I, it's we.
So you're just as guilty as I am for teaching it this way.
BRIAN YU: This is true.
DAVID MALAN: Two, that would have been an amazing moment in a Law and Order
episode, where on cross you get me to contradict myself like this.
And that's actually a really thoughtful challenge.
And I don't think in all the chats I've personally ever had about languages
that someone framed it quite like that, to be honest.
And for those listening, and this is not planned.
I did not see this question in advance.
So I think my pushback would be--
it's I think harder to justify, at least in the context of one course--
or it would be harder for me to justify in the context of one course--
going from a higher level, language like starting with Python,
and then diving more deeply into C insofar
as it probably doesn't really solve problems for students in the same way.
Most of our students and most students, daresay,
who are studying to become software engineers
or who just want to apply programming in other domains,
they're not going to have to bother with C
and it's lower level optimizations and the performance
that you can squeeze out of it.
That's arguably, at least in the real world--
I daresay-- more of a specialized field or specialized use case for language
where you really do want to be as close to the hardware as possible.
And so I worry that that approach, that sequencing of things
would invite more of a who cares or why are we doing this now.
Whereas, if we can start from the older, the lower level language
and just give ourselves enough training wheels early
on that we don't have to trip over some of the harder language
features like pointers and what a string actually is underneath the hood,
we can peel those off but still be in that original language
and then step from that level to the next.
So I do concede that there's a bit of built in contradiction here.
But to me it feels like the nicer balance--
start with the smaller, the more primitive language,
layer on some training wheels, take them off.
And then after taking those training wheels off,
motivate a fundamentally different approach, different language
altogether.
That narrative just makes more sense to me.
BRIAN YU: Yeah, and I can definitely sympathize with that.
Once you've motivated Python and you've started to experience that,
it's very difficult to imagine more situations
where you would want to use C, especially
for students for which CS50 is they're only programming class
that they end up taking for it.
DAVID MALAN: Well, and that, too, honestly.
I really do want students to emerge from CS50,
whether they're taking it here on campus or just online at their own pace,
really not just being a programmer or a software developer,
but really thinking themselves as a budding computer scientist, someone
who can think thoughtfully and critically about these very same issues
so that ideally some of our students can actually
have this same religious debate.
And maybe they'll fall on the other side of it.
But at least they understand the primitives involved
and the trade offs involved with which to come up
with that opinion themselves.
But your question about pedagogically downsides, too--
I mean, there are other side effects.
I daresay-- and you know this better than anyone lately,
as you try to develop new problem sets for CS50 this coming year--
that it's really hard to do cool things in C for some definition of cool.
If we want to do more modern techniques that [? pertain ?] to software
features that students might see on their laptops and desktops and phones
these days, like image manipulation or sound manipulation or features that
exist in a lot of today's most popular apps,
it is arguably harder to do that in C because you don't have off the shelf
libraries left and right that can solve these problems for you.
And even if there are, their APIs, their usage
might be a little more sophisticated than students
are ready for after just one or two weeks of C. Case in point,
I have long wanted us to be able to introduce file I/O earlier
in the semester so that, in week one of the course,
we could actually have students read data from a file.
Now we could absolutely provide in CS5O's own library
one or more functions that does this.
But as much as we've discussed internally how best to do this,
it's not quite as simple as just having one function, like a get file or read
file, that hands you back an array of all lines.
Long story short, we start to trip over some limitations of C
where we might need a second function to help navigate things to close
the file, for instance, or we might need a specialized data type
to represent the data from a file.
At which point it just feels to me like now
we're putting on too many training wheels
and we're trying to use the language for what it's not really
best for, at least in an introductory programming context.
So we pay that price.
And there's a reason that CS50's early p sets are fairly textual
and not nearly is as cool I think as some of the mid or late p
sets in the course.
BRIAN YU: Yeah, I definitely see that challenge.
And for listeners who might not be too familiar with how
C differs from other programming languages with regards to files
and file manipulation, different programming languages
use different abstractions.
So in a language like Python, for example, with one line of code,
you can open up a file and read it for that you
have the entire contents of the file that you can very easily manipulate
and begin to work with, whereas in C there's multiple steps involved
of first opening up the file.
And you have to decide how much memory you're going to allocate.
And you have to do a separate call to read the data from the file
into memory.
So it is a little bit trickier to be able to write
problems that are easily accessible in C that deal with files for instance.
DAVID MALAN: Yeah, and honestly, another issue
we've been wrestling with this summer is portability of code.
Well, we have always in if CS50 used a Linus or a Unix environment, even
before my time.
And that's the architecture on which we've standardized for students.
However, in recent years, the past 10 plus years
have we focused on making CS50's materials and software as portable as
possible, all of our open source tools, including CS50's own library for C.
But unfortunately with C do you run into some architectural specific details
like the size of various data types.
It varies by machine sometimes what and int is
or how many bytes or bits it takes up, a double or float or a long long.
And so case in point, most recently have we
been wanting to deprecate-- that is, kill off--
a function that for many years in CS50's library
was called get long long, because in recent years
we've migrated our own cloud architecture
and students laptops have essentially evolved into being
64-bit machines instead of 32-bit machines,
which has had the side effect, if you will,
of making longs twice as long as an inch.
So instead of 32 bits, they are 64 bits on most platforms like Linux,
and Mac OS, but not Windows.
On Windows, a long is still 4 bytes, or 32 bits, which
means if you were to work on CS50's problem sets or programming assignments
on your own Windows PC and you are using the CS50 library and you use a long,
you might actually only be getting 4 bytes of storage, not 8, which
means you could actually have errors on Windows
that you wouldn't with the exact same code on Mac OS or Linux.
So even those kinds of frustrations come with C.
But however, it's a less common case I think for students
to be working on CS50's p sets on their own windows computers
and not using our environment like CS50 sandbox or IDE or cli50 these days.
BRIAN YU: So I also wanted to ask about it CS50's problem sets
and whether C is the right language for these,
whether you could imagine doing these sorts of problems in other languages.
So Game of 15, for example, which is the problems that we
assign in the third week of the class approximately.
And we ask students to implement one of those 15 puzzles
with the sliding tiles.
If you were to implement that outside of the context of the course,
is C the right language choice for it?
Or would you use some other language for that?
DAVID MALAN: So I think I should first stipulate
that C is rarely the right language for any of the problems
that we might do in problem sets because the reality is you can probably
implement most CS50's problem sets more easily, more quickly,
more pleasantly in languages besides C. With that said, Game of 15
essentially boils down to a two dimensional array
of numbers, the goal being to arrange the numbers from top to bottom, left
to right, from 1 to 15, leaving just one blank space in the bottom right hand
corner.
And honestly, that is a problem that could
be solved pretty readily in almost any language
because you're pretty much just navigating a two dimensional data
structure and looking up, down, left, right to figure out
if a move is valid for instance.
I think the GUE, which is a very simplistic GUE that we implement right
now, could probably be done a little more pleasantly
in other languages, especially ones that lend themselves to graphics.
So we are not even using graphics in Game of 15.
We are just using ANSI control characters so as
to clear the screen instantly and create the illusion of animation.
And that's about as good as you can get with C until you use a proper library,
like the ncurses library, which I'll add as an aside,
we used to use years ago for fancier game interfaces.
But I think Game of 15 is perfectly fine in C.
But you could have a better UI more easily using other languages.
BRIAN YU: And what about some of these CS50's other problem sets?
So one that comes after a Game of 15 is usually resize,
which is a image manipulation problems that where
students are asked to take a bitmap image and scale it up, make it bigger,
or make it smaller, for example?
DAVID MALAN: Yes, so with anything involving images,
most any other language is going to be easier
because odds are you can import some library
and do what we are doing with resize, resizing images, with one line of code.
So yes, if I were in the real world to be implementing a program
to resize images that I couldn't just download myself,
like ImageMagick, which is a free open source tool
chain for image manipulation, I would probably just use Python for that.
Though, I gather Java is pretty good at image manipulation as well.
But most languages have libraries built in that would make that easier.
But I would probably reach for Python these days.
BRIAN YU: Actually, that reminds me of another question
that I was meaning to ask you.
So you mentioned that C is the programming language that
is taught in CS50 but was also taught in CS50
before you started teaching CS50, whereas Python, that's
a little bit different.
Because a couple of years ago the class was
taught using PHP in the latter half of the course.
And recently, you transitioned the class to being taught in Python instead.
I was curious about that decision process.
Was Python the obvious choice?
Were there other languages you were considering?
Or what was the thought process that went into figuring that out?
DAVID MALAN: Oh, also a question that I think
we answered on Quora some time ago.
This too is an FAQ.
So for many years, we did use PHP.
And that was the change we made early on in 2007 when I took over the course,
whereas in recent years prior the course had been introducing students
to a bit of Ruby--
I believe not for web programming, but just as a follow on language to C.
At the time, I didn't know Ruby.
I did know PHP.
PHP was certainly very much in vogue for web programming.
And that was my pedagogically goal, to introduce students
at the tail end of the semester to web applications,
including some SQL and JavaScript and HTML and CSS, all of which
of course were popular by then as well.
And what I liked about PHP at the time was frankly
its documentation was just stellar.
Every page is standardized on these PHP's website.
It gives you really good examples that allow you to dive right
in and use functions quickly.
And it was just very accessible.
And syntactically PHP is just so similar to C, at least
as we present it to students.
Pretty much the only salient difference is like dollar signs
need to be prefixed to variable names.
But for the most part, almost every other construct
is the same as in C. That was a really nice stepping stone,
to go from C to PHP.
But the time came by mid 2010s that PHP was definitely falling out of favor.
Python was becoming more popular.
Ruby was definitely more popular, or at least was gaining more steam.
So the first derivative of these languages
was probably higher than PHP was at the time.
And so at some point, it just felt like the right thing
to do in terms of just trends in so far as half of CS50 students
are never going to take, we know statistically,
another computer science course before.
But they are going to go off to some other domain
and apply programming principles in whatever areas of interest to them.
We wanted them to have something that was a little more familiar and trending
at the time.
However, pedagogically that argument could
have been made even a few years prior.
What really put me over the edge was just changes in industry paradigms
when it came to web programming.
So it was becoming increasingly common not to take PHP's approach
of having every file serve as its own controller,
so to speak-- so index dot PHP and foo dot PHP and bar dot PHP and baz dot
PHP, but rather to start routing all incoming HTTP
requests through an incoming controller of sorts.
Maybe it's all requests go through index dot PHP
and you somehow implement within that and more files your actual routes.
And it got to the point where in the CS50's problem set seven
at the time, CS50 [INAUDIBLE],, we were going to provide students
finally with a rounding framework so that we mimic this industry standard
paradigm where all of your requests are coming in through central controller.
And at that point, we were so adding on to PHP
things that just existed, not only in PHP frameworks,
but in other languages frameworks, like Flask for Python,
that it felt like we were no longer using PHP for what it was
so wonderfully pedagogically helpful for, which was early on the one
to one mapping between text files, something dot PSP, and routes
in a web page.
It was very nice and simple that if a student wants
to implement a foo route, they implement foo dot HP, and a bar route,
bar dot PHP.
But the reality is that is done more centrally in many frameworks
these days.
And so that is what finally put me over the edge.
If we were going to so abstract away some of the underlying design
features of PHP with our own mini framework,
we might as well just adopt altogether a framework.
And at that point, that opened the gates to any number of languages
in Python, [? one ?] out for us.
BRIAN YU: Yeah, Python definitely seems to have gained a lot of popularity
recently.
I was just looking at last year GitHub Octoverse
report, which is the report where they take all of the GitHub repositories
that are online and do some analysis and do some looking at the data there.
And it looks like, since 2014, Python went from the fourth place most common
programming language for repositories on GitHub to the third place
now, just behind JavaScript and Java.
Although I guess on the flip side, since 2014,
C seems to have gone down from seventh place down to ninth place.
So I guess as a follow up question to bring things back to why C,
it looks like we eventually made the transition to Python because of changes
in industry trends and because Python was getting more popular.
In the longer term, maybe years down the line,
do you see the course eventually moving away from C as a programming language?
DAVID MALAN: Good question.
Maybe.
I mean, at some point, it's probably going
to be a little clinging to the past.
I don't know where that inflection point is.
It doesn't feel like it's on the horizon.
I mean, C is still quite popular.
It's been with us for decades now.
It's the foundation in some sense of many other languages
either in terms of its syntactic inspiration or just
the underlying software.
Like the interpreters and the compilers we use are with high probability
written in C, maybe C++ for performance reasons and so forth.
So it's really not going away, I think, anytime soon, whereas in industry,
when it comes to web programming-- again,
the domain that we like to explore at the end of the semester--
I think there's a more rapid rate of change
when it comes to languages being in or out of vogue or frameworks certainly
that are in or out of vogue.
And I should mention, too, that with Python the other characteristic that
put me over the edge mentally when it came to making the final call
was that Python is just wonderfully well rounded, too.
It can be used and is used quite popularly for web programming
as with Flask or Django or other frameworks.
But it's also very commonly used for scripting,
for smaller applications, for command line programs,
for data science applications, data analysis.
So there's any number of different use cases.
And PHP was, to its credit, designed for the web.
But it wasn't really intended to be for data science,
for command line applications and so forth.
You can use it for that.
And indeed, we did for many years.
But it just wasn't really designed with that in mind,
whereas Python is generally pretty commonly found
in both of those domains.
So it just felt like the more versatile tool to have in your toolkit,
so to speak.
BRIAN YU: So you've talked about some of the qualms with PHP.
And you mentioned with C, it's difficult to teach file I/O early on because it
is a little complicated.
What about Python?
Any qualms you have with Python as a programming language or things you wish
were different?
DAVID MALAN: Yes!
I think its documentation is not good, certainly
in comparison with something like PHP.
I think Python's documentation really does
assume a more comfortable audience, which I think is to a fault.
I think that the language itself would benefit
from just much more user friendly documentation
and frankly more thorough documentation and more standardization of formatting
thereof.
Right now a lot of the Python libraries essentially
have a paragraph per function.
But it doesn't sometimes make super clear, especially
to a less comfortable student, exactly what all of the arguments are
and what they're definitions of, what the return types are,
what exceptions might be raised from a certain function,
whereas PHP and Java and a few other languages ecosystems
have done I think a much better job at standardizing
how the documentation is presented.
It's perhaps a bit more verbose with [INAUDIBLE] lists or the formatting
with which the information's presented.
But for newbies, I think that's especially important and just
pragmatically helpful to be able to skim documentation in some uniform fashion
and not as in Python, as too often the case,
cross reference one function with another
because it happens to have the same signature or the same arguments
as this other function.
I'd much rather the documentation just duplicate that information
and maybe put it in one canonical place on the server
but have it imported in multiple places.
I think the documentation could be much, much improved.
BRIAN YU: And speaking of documentation, I
know that the canonical reference for C documentation
for functions in the libraries or the function of man pages
that describe as a manual of what the function does and how it works.
But honestly, I found those to be somewhat arcane, too,
especially for students that are just getting
started with C as their first introduction
to programming and understanding, what the functions do and how they work.
They're not the easiest things in the world to read.
DAVID MALAN: Oh, yes, those are perhaps arguably worse.
So you asked me only about Python.
You didn't ask me to impune C as well.
But yes, and that's actually been an issue for us for many years.
And we for many years tried to assuage this concern with our own website,
which was called CS50 reference.
And what we essentially did one summer some years
ago was a number of our teaching fellows, or TFs,
kindly sat down and wrote more user or beginner friendly versions
of various man pages.
And we encourage students to use this web based tool
to look up information in man pages.
Just this summer, though, have we switch to a new tool, which
is CS50's own adaptation of man pages that you
would find on a typical Linux or Mac OS system at man dot CS50 dot io.
So these are those raw, arguably arcane man pages.
But what we've begun to do is, using some fancy regular expressions
or pattern matching, have we've begun to overlay little hints on top
of key words or phrases that tried to explain,
similar in spirit to help 50, another of CS50's tool,
what it is some piece of language or some piece of English
actually means in those man pages.
And it remains to be seen if this is better.
But this is more consistent with what we have
done most recently with help 50, which is we do not hide arcane error
messages from students.
We want them to see the raw output for better or for worse
that they would see in the real world with any number of the tools
that we use.
But we do want to lower the bar to them understanding those error messages.
So in the case help 50, a command line tool that parses program's output
and then translates them to a more human friendly explanations thereof,
man dot CS50 io does the same thing by showing the student first and foremost
the actual if arcane man page.
But we collapse some of the sections that
probably aren't germane to the question the student's trying to answer.
We put little yellow on hover attributes essentially,
or JavaScript tricks, to show them more information
about certain phrases within the documentation
so as to chip away at that problem.
It would be a non-trivial undertaking to do the same for Python.
We're not there yet.
I'm not sure if we will.
But I think there are opportunities in both.
And again, to its credit, I think PHP out of the box
does this very well as a language.
BRIAN YU: You mentioned C's error messages.
And that reminded me of another qualm I have with Python.
Just how long the trace backs when you get
an error message can be that oftentimes, when
students are writing using frameworks like Flask in this class
during their work with Python, when they have an error in their code,
they get this incredibly long trace back that references so many
files that they haven't even written and haven't looked at and haven't touched.
And it can just be difficult when they're first
getting started to look at that and understand what their actual error is
and where they made a mistake as opposed to all of the different places
where the exceptions are happening in the Python code.
DAVID MALAN: Yeah, absolutely.
And the rule of thumb would be, well, look
for the line in that trace back that mentions your file and your file
number.
But we actually do consistent with help 50,
with man dot CS50 dot io, actually do try
these days, the past couple of years, to help students see through that noise,
if you will.
So if you so much in Python as have a single line import CS50 at the top,
you don't actually have to call any functions.
We, doing some technique called monkey patching, importing other libraries
and tweaking certain code settings, are we
able to for those tracebacks highlight in yellow for students only those lines
that pertain to their code, leaving black and white,
the lines of code that are unrelated to theirs, for the same purpose.
We want them to see everything.
We want them to see the noise.
But we want to help them see through the noise as by highlighting,
much like help 50 and man dot CS50 dot io, portions
that are actually relevant to them.
So we hope, too, that this strikes that right pedagogically
balance without sweeping too many details under the rug.
BRIAN YU: And I guess that kind of gets back us
to the why C of letting people feel the noise without sweeping
the details under the rug.
DAVID MALAN: Yeah, so I'd like to think--
and the more we chat I'm reassured to hear that I think
we're being self consistent throughout.
But this is absolutely thematic.
There have been, though, I'll admit, some
psets in the past where honestly we probably shoehorned in C,
where it just wasn't really very pleasant.
So case in point, a few years ago, we had
a pset that called Server, where students actually needed
to implement the guts of their own web server-- so not a web application,
not a website per se, but an actual program written in C that listens
for HTTP requests and responds to them
the exercise, though, ended up really becoming quite the tedious exercise
in parsing strings in C, which wasn't really
the intent because we do that of course very early on.
And we, too, have CS50 students parse strings
and understand char stars and representation
of strings as arrays of characters.
But this one came later in the semester.
And while it was a wonderful transition, I THINK conceptually from C
to web programming by actually implementing
in C the foundation for web programs, it really
was incredibly tedious to parse HTTP request lines.
That is the sort of thing that is much more
pleasant to do in almost any language, Python among them.
In C it really is a little frustrating.
And so that I felt like now we're using the wrong language even
for the right problem sets.
BRIAN YU: Even in Python I feel like having
to parse the HTTP requests on your own would be a tedious task.
And I'm glad that there are frameworks out there like Flask and Django
that just handle a lot of the stuff for you
and make it easier just to focus on the more interesting parts of web
application design and development.
DAVID MALAN: Oh, yeah, absolutely.
And that's why we use Flask.
We don't implement Flask.
But in other years ago, we had a pset inspired
by Eric Roberts of Stanford called Breakout, which is that old school
game where you can bounce a ball off a paddle
and you try to break these bricks that are colorful in the sky.
So it's actually non-trivial to do that in C, especially
in our environment when you don't necessarily
have a proper C GUE, a Graphical User Environment,
like something called X Windows, because our most recent incarnations
of CS50, of course, have students using web IDEs.
Ideas.
So in a nutshell, back in the day when we were still
using a virtual machine with students, the so-called CS50 Appliance, which
they ran locally in their Macs and PCs, we actually used C and some code
that Eric Roberts had written, which itself was written in Java because Java
allows you to do graphics a little more easily in a way that was also
cross platform.
We had this bridge called the Stanford Portable Library,
or SPL, that allowed students to implement this really cool interactive,
animated game called Breakout in C by using a nice pedagogically simplified
library.
But when we finally transition to more of a web based environment,
that actually complicated that.
So it's been a few years since we've used Breakout as a game.
BRIAN YU: On the other hand, are there any problems
that you think really cleanly in C where the solution in C
is very elegant, very nice?
DAVID MALAN: Mario, I think, lends itself wonderfully to C,
although of course you can probably implement Mario
in like two lines of Python code instead of six to 10 or so in C.
But I think some of the early psets in CS50
could certainly be done pretty easily in C, like Caesar, which
is a problem set on cryptography where students have to encrypt or decrypt
information.
That's nice because it lends itself to pretty simple user input.
You type in a string, and then you iterate over that string character
by character and then do a bit of arithmetic using Ascii or Unicode
values to convert it to the ciphertext or conversely to the plaintext.
So that works perfectly well in C. And even though, yeah, you
could save a few lines in Python, C is perfectly fine for those kinds
of string manipulations.
Game of 15, where we began the story, I think works perfectly fine in C,
even if the GUE might not be as pretty as you might
get more easily with another language.
The spell checking assignment that we do where we give students
like 140,000 words in a big text file, and they have to load it into memory
and implement their own hash table or some other data structure,
that is particularly well suited for C when performance matters to you.
You want to use as few CPU cycles as possible, as a little RAM as possible,
because with the power and capabilities of something
like Python comes a non-zero amount of overhead CPU cycles and bites of RAM
that are wasted on the overhead or the abstractions that it provides.
And in fact, pedagogically what's nice about doing that pset in C
and then reimplementing it a week or two later in Python in lecture
is that students can see, oh my god, you can implement the spell
checker in just a few lines of Python despite 20 hours of coding
in C on that same problem.
But when you compare their performance side by side,
you see that generally the Python version
takes a non-trivial amount of more time to actually run.
And so that's one of the goals even of that.
Of course, I wouldn't want to implement something like CS50 finance in C
or really anything for the web in C. While you can absolutely do it,
it's entirely unpleasant or way more time consuming than you'd want.
So I think finance has always lent itself to PHP in the past
or more recently Python, though it is one
that could be implemented in any number of other languages or frameworks--
Ruby, C sharp, Java, or others.
BRIAN YU: Now that you mention it, the speller assignment really I think
lends itself well to C because, whereas in Python there's
really just one way to do that right, in C there are so many ways.
And it's been really cool to see students online
that are all tackling the misspellings problem in various different ways,
trying to figure out how to optimize it and make it perform the best.
And we have this online scoreboard where students online can compete
against each other to see how quickly they're
able to spell check these documents by writing
their most efficient implementation in C.
And it's fun to watch people compete in that
and try and figure out what the best way to do it is.
I mean, so suffice it to say, without any discussion about language,
everyone brings to the table his or her own, I think,
preferences work or religious beliefs.
DAVID MALAN: I'd like to think, though, that C has definitely
helped us pedagogically solve some problems,
or it has allowed us to implement a particular vision we
have for the trajectory we want students to have from day 0 to day n minus 1.
It's certainly not without its downsides or costs
in terms of cognitive difficulties or just actual technical bugs
that students run into.
But I'd like to think, certainly after this many years,
that we have enough success stories of students exiting from the course.
And even though they might never want to touch C again,
that's fine because truly, at the end of the semester, where
we end, for instance, here with the so-called CS50 fair and campus
wide exhibition of students final projects,
every year for like 11 years now of CS50 fairs
have I genuinely been struck at how many students go off and implement
something, create something, build something
on topics, on languages, using tools that we ourselves didn't teach them
in the course.
And I would really like to think that is largely attributable, not
to the course per se, but to the scaffolding that the course happens
to provide to students and the takeaways that they hopefully have,
which is that they understand some underlying implementation details that
are perhaps unique to a course like this or the relatively few courses
out there that you start at this level of abstraction that's pretty close to
but just above the level of hardware but exit
with more modern, with more powerful, higher level languages
and techniques that allows a student who three months prior had never touched
a line of code before to make his or her own iPhone application, web
application,
or any number of other tools.
So I like to think we're doing something right here along the way.
BRIAN YU: Yeah, that's also amazing to see at the fair.
DAVID MALAN: But do feel free, as always, out there to agree or disagree.
Feel free to chime in with comments of your own perspective on languages
or your own experiences positive or negative
with C, with CS50, with Python, PHP, and any number of other languages.
And indeed, we invite you to contribute your own ideas
for the podcast moving forward.
Just as this week was inspired by a past Quora post,
last weeks was inspired by a Facebook poll on machine learning.
We'd love to hear what topics are of interest to folks the most.
BRIAN YU: If you have ideas or you have feedback about today's episode,
you can feel free to reach both of us at podcast@csfo.harvard.edu.
DAVID MALAN: Thanks so much for tuning in.
This was the CS50 Podcast.