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