DAVID J. MALAN: All right.

So this is CS50.

And this is week 1, the one in which you learn a new language, which

is something we technically said last week, at least if you had never

played with this graphical language known as Scratch before, which itself

was a programming language.

But today, as promised, we transition to something

a little more traditional, a little more text-based,

not puzzle piece- or block-based, known as C.

This is an older language.

It's been around for decades.

But it's a language that underlies so many of today's more modern languages,

among them something called Python that we'll also

come to in a few weeks' time.

Indeed, at the end of the semester, the goal

is for you to feel that you've not learned Scratch,

you've not learned C, or even Python, for that matter,

but fundamentally that you've learned how to program.

Unfortunately, when you learn how to program

with a more traditional language like this, there's just so much distraction.

Last week I described all of the syntax, all of the weird punctuation

that you see in this, like the hash symbol, these angled brackets,

parentheses, curly braces, backslash n, and more.

Well, today we're not going to reveal what all of those little particulars

mean.

But by next week, will this no longer look like the proverbial Greek

to you, a language that, presumably, you've never actually seen or typed

before.

But to do that, we'll explore some of the very same topics as last week.

So recall that, via Scratch-- and presumably via problem set 1--

we took a look at things called functions that are actions or verbs.

And related to functions were arguments like inputs.

And related to some functions were returned values like outputs.

Then we talked a bit about conditionals, forks in the road, so to speak,

Boolean expressions, which are just yes/no questions or true/false

questions, loops, which let you do things again and again, variables,

like in math, that let you store values temporarily,

and then even other topics still.

So if you were comfortable on the heels of problem set 0 and last week,

realize that all of these topics are going to remain with us.

So really, today is just about acquiring all the more of a mental model for how

you translate those ideas into, presumably, a very cryptic new syntax--

a new syntax, frankly, that's actually more

simple in some ways than your own human language,

be it English or something else, because there's far fewer vocabulary words.

There's actually far less syntax that you might

have in, say, a typical human language.

But you need to be with these computer languages all the more precise

so that you're most, ultimately, correct,

and ultimately will see to your code is successful along a few other lines

as well.

So if you think about the last time you kind of wandered around not really

knowing what you were doing or encountered something new--

might not have been that long ago, entering Harvard Yard for the very

first time, or Old Campus or the like, be it in Cambridge or New Haven--

you didn't really need to know how to do everything as a first year.

You didn't need to know who everyone was,

where everything was, how Harvard or Yale, or anything else for that matter,

worked.

You sort of got by day to day by just focusing on those things that matter.

And anything you didn't really understand,

you sort of turned a blind eye to until it's important.

And that's, indeed, what we're going to do today.

And really, for the next several weeks, we'll

focus on details that are initially important

and try to wave our hands, so to speak, at details that, yeah, eventually

we'll get to, might be interesting.

But for now, they might be distractions.

And by distractions, I really mean some of that syntax

to which I alluded earlier.

So by the end of today-- and really, by the end of problem set 1,

your first foray, presumably, into this language called C--

you'll have written some code.

And you'll be asking yourself-- we'll be asking yourselves--

just how good is that code?

Well, first and foremost, per last week, be it in Scratch

or phone book form, code ultimately needs to be correct, to be well done.

You want the problem to be solved correctly.

So that one sort of goes without saying.

And along the way this term, we'll provide you with tools and techniques

so you don't have to just sit there sort of endlessly trying an input,

checking the output, trying another input, checking the output.

There's a lot of automation tools in the real world--

and in this class and others like it-- that

will help facilitate you answering that question for yourself, is my code

correct, according to our specifications or the like.

But then something that's going to take more time

and you're probably not going to feel 100% comfortable with the first week,

the first weeks, is just how well designed your code is.

It's one thing to speak English or write English,

but it's another thing-- or any language, for that matter.

But it's another thing to speak it or write it well.

And we spend all these years in middle school, high school, presumably,

writing papers and other documents, getting grades and feedback on them

as to how well formulated your arguments were, how well structured

your paper was, and the like.

And there's that same idea in programming.

It doesn't matter necessarily that you've just solved a problem correctly.

If your code is a complete visual mess, or if it's crazy long,

it's going to be really hard for someone else

to wrap their mind around what your code is doing and, indeed, to be confident

if it is correct.

And honestly, you-- the next morning, the next year,

the next time you look at that code-- might have no idea

what you yourself were even thinking.

But you will if you focus, too, on designing good code,

getting your algorithms efficient, getting your code nice and clean,

and even making sure your code looks pretty, which

we'd describe as a matter of style.

So in the written human world, having punctuation in the right place,

capitalization and the like-- the sort of way you write an essay

but not necessarily send a text message--

relates to style, for instance.

And so good style in code is going to have

a few of these characteristics that are pretty easily taught and remembered.

But you just have to start to get in the habit of writing code in a certain way.

So these three axes, so to speak, correctness, design, and style,

are really the overarching goals when writing code that

ultimately is going to look like this.

So this program we conjectured last week does

what if you run it on a Mac or PC or somewhere else, presumably?

What does it do?

Yeah?

AUDIENCE: [INAUDIBLE].

DAVID J. MALAN: It just prints, Hello, world.

And honestly, that's kind of atrocious that you

need to hit your keyboard keys this many times with this cryptic syntax just

to get a program to say, Hello, world.

So a spoiler-- in a few weeks' time when we

introduce other, more modern languages, like Python,

you can distill this same logic into literally one line of code.

And so we're getting there, ultimately.

But it's helpful to understand what it is that's going on here,

because even though this is a pretty cryptic syntax,

there's nothing after this week and, really, next week that you shouldn't

be able to understand even about something that right now looks

a little something like this.

So how do you write code?

Well, I've given us sort of the answer to a problem.

How do you print, Hello, world, on the screen?

So what do I do with this code?

Well, we're in the habit of typically writing things with, like, Microsoft

Word or Google documents.

And yeah, I could open up Word or Google Docs or Pages or the like

and just literally transcribe that character for character,

save it, and boom, I've got a program.

But the problem, per last week, is that computers only understand or speak

what other language, so to speak?

AUDIENCE: [INAUDIBLE].

DAVID J. MALAN: Yeah, so binary, zeros and ones.

And so this, obviously, is not zeros and ones.

So it doesn't matter if I put it in a Word doc, Google Doc, Pages file,

or the like.

The computer is not going to understand it until I somehow

translate it to zeros and ones.

And honestly, none of those tools that I rattled off

are really appropriate for programming.

Why?

Well, they come with features like bold facing and italics

and sort of fluffy, aesthetic stuff that has no functional impact on what

you're trying to do with your code.

And they don't have the ability, it would

seem, to convert that code ultimately to zeros and ones.

But tools that do have this capability might

be called Integrated Development Environments, or IDEs,

or, more simply, text editors.

A text editor is a tool that a programmer uses perhaps every day

to write their code.

And it's a simple program-- here, for instance, a very popular one

called Visual Studio Code, or VS Code.

And at the top here, you see that I've actually

created in advance before class a very simple empty file called "hello.c."

Why?

Well, .c indicates by convention that this is going to be a file in which

there is C code.

It's not .docx, which would mean in this file is a Microsoft Word document,

or .pages is a Pages file.

This is .c, which means in this file is going to be text in the language called

C. This number 1 here is just an automatic line number that's going help

me keep track of how long or short this program is.

And the cursor is just blinking there, waiting

for me to start typing some code.

Well, let me go ahead and type out exactly the same code.

For me, it comes pretty comfortably from memory.

So I'm going to go ahead and include something called standardio.h--

more on that later.

I'm going to magically type int main(void), whatever that means--

we'll come back to that later--

one of these curly braces and then a sibling there that closes the same.

Then I'm going to hit Tab to indent a few spaces.

And then I'm going to type not print, but printf, then "Hello, world," /n,

close quote, close parenthesis, semicolon.

And I dare say this was essentially the very first program I wrote some

25 years ago.

I wrote it to say, "Hi, CS50."

Now it just says the more canonical, conventional, "Hello, world."

But that's it.

That's my very first program.

And all I need to now do is maybe hit Command-S or Control-S

to save the file.

And voila, I am a programmer.

The catch though, is, OK, how do I run this?

Like, on your Mac or PC, how do you run a program?

Well, usually double-click an icon.

On your phone, you tap an icon.

In this environment that we're using and that many programmers-- dare

say most programmers-- use, you don't have immediately a nice, pretty icon

to double-click on.

That's very user friendly, but it's not very necessary.

Especially when you get more comfortable with programming,

you're going to want to type commands because it's just faster than pointing

and clicking a mouse.

And you're going to want to automate things,

which is a lot easier if it's all command or text-based, as opposed

to mouse and muscular movements.

And so here I have my program.

It lives in this file called "hello.c."

I need to now convert it, though, to zeros and ones.

Well, how do I go about doing this, and how am I going to get from this

so-called code--

or source code, as it's conventionally called--

to this, these zeros and ones that we'll now start calling machine code.