Skip to main content

Professor Answers Coding Questions

UC Berkeley Computer Science Professor Sarah Chasins joins WIRED to answer the internet's burning questions about coding. How did programmers code the first ever code? What remnants of the early World Wide Web still exist online? Can someone still learn programming if they hate math? How do new programming languages get made? Why is debugging harder than writing code? How can computer scientists contribute to CRISPR? Professor Chasins answers these questions any many more on this episode of WIRED Tech Support: Coding Support. Director: Justin Wolfson Director of Photography: AJ Young Editor: Richard Trammell Expert: Sarah Chasins Line Producer: Jamie Rasmussen Associate Producer: Brandon White; Paul Guylas Production Manager: Jonathan Rinkerman Casting Producer: Nick Sawyer Camera Operator: Nick Massey Sound Mixer: Gloria "Glo" Hernandez Production Assistant: Fernando Barajas Post Production Supervisor: Christian Olguin Post Production Coordinator: Stella Shortino Supervising Editor: Eduardo Araujo Assistant Editor: Billy Ward

Released on 12/09/2025

Transcript

I am Sarah Chasins.

I'm a professor of computer science at UC Berkeley.

I am here today to answer your questions from the internet.

This is Coding Support.

[upbeat music]

texguy21, or it could be texguy21,

it depends on if it's a reference to law tech or not,

says, What remnants of the early World Wide Web are left?

And it turns out that the first website

that was ever put up is still available to us,

so I actually have it here on my laptop right now.

So this is a webpage put up in the early nineties

by Tim Berners-Lee.

It's describing what the World Wide Web is,

because Tim Berners-Lee is actually the person

who created the World Wide Web,

and we can see that it still displays

in a totally readable and manageable manner

in our modern web browsers, right?

This is just Safari, but someone also actually recreated

what it would've looked like in a browser at that time,

so here, we can see, we've got the World Wide Web.

It's all the same content,

but of course, it shows up very differently,

because the machinery they were working with

at the time was working differently,

the browsers they had made at the time

were working differently.

It's giving us instructions

on how to actually browse through the rest of the page,

but it's all the same content.

Obviously, it's showing up a little bit differently.

Admirable_Long9546 asks, New to coding.

Is it always this difficult?

The easy answer? No.

Every skill that you have ever learned in your life

where parts of it became automatic over time,

when you started riding a bike, eventually became automatic,

when you started playing guitar, started becoming automatic,

the exact same thing is gonna happen with programming.

No_Confidence_5070, oh, I'm sorry about the username,

asks, Can I still learn programming if I hate math?

The answer is yes, absolutely, absolutely 100%.

So there are some kinds of math

that make some kinds of programming easier,

but it's not all kinds of math,

and it's not all kinds of programming.

That matter, there's some kinds of video games

that give you practice with some of the things

that make programming easier.

There are lots of different skills out there

that you might be practicing that might help you

with some of the same things that you're gonna need

in order to do coding tasks.

Math is one of them. Again, it's not even all math.

There are certainly, there are some types

of computer programming that you might want to do

that probably would demand a little math from you,

so there are parts of the computer programming world

where you probably wanna be comfortable

with some parts of math, but no,

you can absolutely, absolutely,

absolutely get into programming,

get really good at programming, without being into math.

Someone on the internet asks,

What were the earliest computer viruses like?

How did they infect and affect computers?

In about the early seventies,

computers had started to be sort of connected

with each other through something called the ARPANET.

We didn't have the internet yet, and so you could go ahead

and start spreading things that way.

and there was this virus called the Creeper.

It would print something out on the screen

that said something like,

I'm the Creeper. Catch me if you can.

Then they had to come up with the Reaper

to go in and get rid of the Creeper program

that was running on these machines.

Da_Man2010 asks,

How did programmers code the first ever code?

Early, early on there, was the ENIAC.

and the ENIAC was sort of the first computer

that we all look at by modern standards and say, yep.

To us, that looks like a general purpose computer.

It looks a lot

like sort of old-school telephone switchboards,

where you're just plugging together wires

in different parts of it, and that's actually

how you're communicating what you want it to do.

Eventually, folks figured out how to use punch cards,

stiff piece of cardstock kind of a thing,

and you're punching holes in it,

and that was the way that we fed instructions into computers

for a long time before we started storing programs

in memory, so originally,

the humans were just writing those ones and zeros.

This was really painful.

All this manual effort was really exhausting,

it took months, and so this amazing thinker,

Grace Hopper, developed the term compiler.

Grace Hopper was this amazing early computing pioneer.

She was a mathematician, she was incredible,

and came up with the idea that,

instead of all these human people doing compilation,

we should have a program on the machine

that is actually gonna do the compiling for us,

and so that would be the compiler,

and she invented this tool called A0

for putting together a bunch of different sort of portions

of a program, a bunch of different sort

of semi-related portions of code

and getting them to talk to each other,

and that was sort of the predecessor to the modern compiler.

In fact, since that time,

we have piled all this extra stuff on top of it,

so the thing that Grace Hopper wrote in the early fifties

actually no longer even looks like a compiler to us, right?

It looks like one of the sort of subcomponents

of a compiler, 'cause we have all this other stuff

that we've built up on top of it. Better-Sir9013,

What is the difference between programming languages?

Why are some of them considered harder

if they're all just same lines of code?

There are lots of different things

that can set programming languages apart.

A big thing that I tend to think about

is how much they sort of have your back,

so a really common thing is for a programming language

to be automatically trying to capture some kinds of bugs

for you, trying to prevent you from running

into some of the problems

that might come back to bite you later.

Some of them are saying,

You know what? You're on your own.

Just write what you wanna write,

put in whatever bugs you wanna put in,

I'm gonna run it for you, so an example of something

in that general category would be C.

There are other programming languages that are saying,

You know what?

I'm going to try to catch at least some bugs for you,

maybe not all the bugs,

but I'm gonna try to catch some bugs,

and I'm gonna try not to get in your way.

I'm not gonna try to demand a lot of extra information

from you in order to do that,

and so an example of something in that class

would be maybe Python,

and then you might have some other language over here

that is really, really trying to have your back.

It is gonna try to catch as many bugs for you

as it can possibly catch,

and the way that it's gonna do that

is it's gonna demand extra information from you,

so it's gonna make you work harder, but in exchange,

it's gonna catch a lot of those bugs for you.

An example of something in that general zone would be Rust.

Phainesthai asks, Working as a programmer?

What do you actually do all day at work?

Unfortunately, the answer is not as much programming

as you might desire.

In general, a lot of programmers get into programming

because they like programming,

and then it turns out that a lot

of what they're spending their day to day on

is talking with other programmers

about how to get this person's piece of code

to talk with this person's piece of code,

how to make all of this sort of big codebase work together,

or you're talking to the client or the customer

or someone who's gonna be using this piece of code,

and you're figuring out what their needs are.

You're having a bunch of meetings

in order to figure out what the program should actually do,

and then you're squeezing in as much

of that actual coding time as you can,

'cause that's usually the fun part.

DGHolmes asks,

Is Python really the second best language for everything?

I think probably whoever said this first,

honestly, they were probably trying

to get a dig in on Python a little bit,

kind of trying to say that it's not

the first best language for anything,

but the other way of reading this

is to say that Python is very flexible, and it's true.

Python is incredibly flexible.

There's all kinds of programs that you could comfortably go

and write them down in Python.

You're probably gonna have a good time.

I have a personal fondness for Python,

and I have no bad feelings towards Python, so thumbs up.

Learn Python.

A Reddit user asks,

Is it worth learning C++ in 2025?

Easy answer to this is, absolutely.

The follow-on answer is,

if you're entering an existing codebase

and it's already written C++, okay, great.

It's already written in C++, you're gonna probably use C++.

On the other hand, if you are starting a new project,

see if you could use Rust.

Just take a look.

royrustdev says,

Why is Rust the most loved programming language

in StackOverflow surveys?

Why do you love Rust?

Do you try to convince others to learn Rust?

Rust is probably one

of the most exciting new-ish programming languages

that we have available right now.

They have been incredibly thoughtful

about so many different parts

of the design of this language.

One of the things that people are really excited about

is just they've been thoughtful about the error messages

that you get when you do something wrong.

Honestly, that does actually matter a lot

when you are getting up and running with a language,

but if you look even more deeply into the design

of the language itself, it is bringing together

sort of the best ideas from the past 20 years

of new research in programming languages land,

so there have been all of these really exciting ideas

about how we can help programs catch more bugs.

this idea of the programming language should have your back,

it should be looking out for the things

that you might do wrong,

and it should be catching those in advance.

Rust is doing that at a level

that the other languages out there

kind of aren't really doing,

while also being just incredibly fast,

so if you are thinking about,

oh, I'm gonna have to use C in order to write this

in order to make sure that it's fast enough to run,

you might also be thinking about Rust at this point,

'cause it's high-performance,

but it's also, again, it's got your back.

Star_Knight12 says, JavaScript is a GOATED language.

I don't know why people hate it for no reason.

I get what you're saying.

I think in general, there are some reasons

to be a little bit skeptical

of some JavaScript's design choices, but basically,

if you're feeling dissatisfied with JavaScript,

just learn TypeScript.

If you're trying to write something out on the web,

and you're so frustrated at being locked into JavaScript,

no problem, learn TypeScript, you're gonna be happy.

This is a very exciting one.

Brilliant-Sir-5729 asks,

How on earth do programming languages get made?

Someone has the idea for,

I would like to write out this kind of program,

I want the program text to say this,

and here's what I want it to do,

and then all of those steps that it takes

in order to convert something

in that high-level representation

all the way down to the ones and zeros,

you are now in charge of that.

The process of doing that is called writing a compiler,

or you might instead write an interpreter.

There are multiple different ways

of implementing a programming language,

but basically yeah, what it takes is an idea,

so you don't necessarily have

to generate assembly instructions, because it turns out,

we have all of these existing programming languages,

and so you can take advantage of that

in order to implement your new language

in a way that's maybe easier for you,

so maybe I wanna invent Unicorn Lang.

I can go and write my compiler

that compiles from Unicorn Lang to Rust,

which is an existing programming language.

Now that I have this Rust program coming out the other end,

I can then feed that into the existing Rust compiler

and use that to actually get all the way down

to the ones and zeros, so you can start stacking together

these different compilers.

cheaplongstake says,

Why do computers just use the binary code zeros and ones?

When we're writing numbers in our day-today life,

we are using base 10, we have the digits zero through nine,

whereas for computers, as we've talked about a bit,

we are using zeros and one, base two.

This is not necessarily innate. This is not enforced.

The very first computer that we all sort of recognize

as a computer, the ENIAC, actually used base 10.

It can be done. You can totally do it.

Remember that the way that we're representing

this information inside the computer

is by how much electricity

is flowing through a part of the computer,

and so go ahead and imagine, I have put you in a room.

There's a light bulb in the room.

On the other side of the wall,

I'm controlling a dimmer switch.

I want you to tell me if we're at the low position

of the dimmer switch

or the high position of the dimmer switch,

and I'm gonna sort of mess around with that outside,

and every time I yell out to you,

you have to tell me, low or high?

If I'm just giving you low and high,

you're probably gonna be able to do that pretty reliably.

I can be a little bit off

in how much I've messed with the dimmer switch,

and you're probably still gonna be able

to shout out low or high.

Now, instead, say I've picked these 10 spots

on the dimmer switch, and I want you to be able to yell out,

zero, one, two, three, four, five, six, eight,

or nine based on where I've put it in there,

but remember, you're in the other room.

You're not seeing what I've actually done

on the dimmer switch, you're just seeing the light bulb,

so say I stick it to five.

Some of the time, you're probably yelling out five,

some of the time, you're probably yelling out six,

and some of the time, you're probably yelling out four.

It can be done to use base 10 inside the computer,

but if you think about sort of, okay, we're really,

we're trying to figure out how much electricity

is flowing through this, it's a lot easier.

It's gonna be a lot more reliable

if you just do the ones and zeros.

Illustrious_Run4733 is asking,

Why is debugging harder than writing code?

It is so much harder.

Basically, the answer comes down to your mental model

of what the program is doing

versus what the program is doing.

If you're going through the process of writing something up,

doing the original draft of your program,

you're not even necessarily at the point of testing

if your mental model is aligned with the program,

but basically, our sort of view

of what's happening this entire time is,

okay, this is what I'm expecting the program to do,

so you are keeping your mental model well aligned

with what the program is doing,

and so you're sort of building up the program bit by bit,

continuing to make sure throughout

that it is doing what you expect.

If we hit the point where we are doing debugging,

where we're trying to find something that has gone wrong,

then our mental model and what the program is actually doing

have diverged,

even harder if it's something that you didn't write,

'cause then you're having

to build up the mental model from scratch.

You don't have any mental model in there to even start from,

so you're having to go through

and do that sort of difficult process of reading code,

figure out, okay,

what am I expecting this program to even do?

Pleasant_Relation144 asks,

How do you guys remember all the syntax?

We don't, necessarily.

It turns out, in contrast to, say I am learning Spanish,

I'm gonna go, and I'm gonna be trying to speak

to someone in Spanish,

I'm not trying to be looking at my computer every time

to translate a word.

In contrast, if I am at the editor

and I'm typing out my code,

I've got the computer right there.

If I've forgotten something, I can just look it up,

and it's no big deal.

red-pyjamas asks, How do I know if I should learn backend,

frontend, or full-stack?

The answer is, you probably don't know in advance.

You really probably just wanna try it,

so it could take a few years to be really,

really comfortable and feeling really like an expert

in any of these spaces,

but to get a sense of what the day-to-day would look like,

to just try it out, in a week or two,

you can probably have a pretty good idea

of what these programs look like

and if you enjoy writing them.

kavinda14 asks,

How can computer scientists contribute to CRISPR?

So I absolutely love this question,

because I'm really excited about work that does bring,

I specifically think about programming languages work,

but also computer science more broadly

into conversation with other disciplines.

I think that's really powerful and really exciting,

and more folks should be thinking about it,

but I think the actual answer here is,

go out and talk to the people

who are doing the work you wanna support,

so one of the pieces of advice

that I give my PhD students all the time,

and they're amazing at doing this, is they'll just go out

and become apprentices to the teams

that are doing the kind of work

that they want to be supporting,

so for example, I have an amazing PhD student

who is currently basically embedded in a biology lab.

He's a computer scientist, but he's learned how to pipette,

he's taken biology classes,

he's in their labs helping with programming tasks.

He is there doing the work

of understanding their day to day,

because unfortunately. it's not quite as simple as, okay,

we can just get everyone sort of from the bio side

to type up one or two paragraphs about their problems,

and off we go.

It takes work to figure out, what are the real gaps there,

and what are the things we could do to fill it?

So go spend time with the audiences, the communities,

that you are excited to serve.

I think it's really powerful.

Senior Pineapple, or perhaps Senor Pineapple, asks,

How hard would it be

to build my own game engine from scratch?

And the answer is, very hard.

You'll probably also have a really fun time, though.

In general, a big thing

that you're gonna spend your time doing

is deciding what abstractions you want your programmers

to have access to, basically,

an idea or a word that they can use repeatedly,

if you have a prebuilt snippet of code

that is gonna do one big, long thing,

but they get to call it by just a short name

and reuse that code over and over again,

and so what you're doing when you build your own game engine

is trying to anticipate, what are those snippets of code

that people are gonna need to reuse and reuse and reuse?

But it turns out for building a real game, for building,

especially if you're thinking about maybe a 3D game,

it's gonna be a lot of different things

that the programmer is gonna need to do,

and it is gonna take you some time to get there.

The other thing is that there are certain parts of,

depending on how low-level you're deciding to go,

like maybe you're building this on top

of an existing game engine, in which case maybe,

you're not gonna have to deal with this,

but if you are going all the way down

to deciding how every pixel is gonna appear yourself,

you're gonna end up doing a lot of computer graphics type

of computation, which involves some amount of math,

so this process is super, super fun,

and if you are interested in game programming,

writing your own game engine is a very interesting exercise,

but it's definitely not gonna be the fastest route

to a game.

Martholomeow asks, Is ChatGPT really as revolutionary

as it seems?

Compared to other tech breakthroughs, I say not so much.

I think it comes down

to whether you are personally interested in tasks

where the goal is to put together words

that look good together.

If that is gonna revolutionize your world, fantastic.

ChatGPT is built on a kind of program

called a large language model.

A large language model is basically a program

for putting together words that look good together,

and so the approach that large language models designers

actually took was, okay, what we're gonna do

is we're gonna go out and collect all of the documents

we can find on the web, all the webpages themselves,

all the other documents we can rustle up,

and these are basically words that humans have put together,

and so we have some pretty good evidence

that humans think these words look good together,

and so we're gonna make it play the fill-in-the-blank game

on these documents.

I might have a simple document,

it says the dog has four legs,

so I'm gonna go ahead and feed that to the program,

and I'm gonna say, Blank dog has four legs.

The first time it answers, it says sky.

You say, no you silly program, not sky.

The word is the. That's the word I want in there.

You go again, you fill in the second word

with a blank instead, so it's the blank has four legs,

and it says swimming.

You say, no, you silly machine,

not swimming, I want a dog there.

So you repeat this process for about 300,

400 years of compute time, 'cause you can split up the work

across a bunch of different computers,

and then get them together

to sort of mash together their cheat sheets at the end.

We've already sort of shown it the answer,

and you might say, Sarah, this doesn't seem okay.

The program is going to be able to cheat.

That is exactly the point.

You are trying to get it to cheat, you want it to cheat,

and so you are going ahead and you're giving this LLM,

this large language model, a cheat sheet,

and if you've ever heard something about sort of the number

of parameters that a particular LLM has,

that is about sort of the size

of the cheat sheet that it was given.

You make it play the fill in the blank game for about 300,

400 years of compute time, and then at the end of that,

you have a program that is pretty good at fill in the blank.

Now, this does not automatically give you ChatGPT,

but it is pretty easy to turn one of these into a chatbot,

because now, we just make a new document,

and it says something like, This is the transcript

of a conversation between a human and a chatbot,

and then the next part of the document

says the human has said, 'What is the capital of Sweden?'

The chatbot has said, colon, blank.

And so it now fills in the blank,

because it's good at playing the fill in the blank game,

and so maybe it says the, and then you go again,

but now it says, The chatbot says, colon, the, blank,

and maybe now the next word it comes up with is capital,

and you just keep going through that process,

going through that process,

and so that is what is going on with large language models.

It's just programs for putting together words

that look good together.

gptgirlnextdoor is asking, With AI advancing so fast,

is it still worth learning to code deeply?

Yes, you still need to be able

to write code the old-fashioned way, for the most part,

in order to get programs out from these generative AI tools,

so the first thing is that a really big skill

that you learn over the course of a programming education

is how to decompose programming problems.

You're starting from this big, amorphous,

sort of not super well specified large problem,

and you're figuring out, okay,

well I can break, it into these two chunks,

and then I can break that chunk into an even smaller chunk,

and you keep doing this all the way down

to something really small, small enough

that you can actually answer it with a single line of code

or a couple lines of code.

If you haven't been trained to do that,

it's not necessarily particularly easy to do,

and so if you're just giving sort of these big, vague,

open-ended things, it's really hard to turn that

into useful program that's actually gonna work and run.

The next big thing that comes up

is the kinds of human language text,

for example, English text,

that I would write if I'm a non-programmer

usually look different from what I would write

if I was a programmer.

Over the course of all the documents

that got fed into the large language model

in order to figure out what words look good together,

the documents that had code in them

were usually written by programmers,

and so those were using

the sort of programmer-style human language descriptions

next to the code,

and so even if the human language descriptions

that a programmer would write might produce good code,

the other alternative ways

of describing those problems might not work.

In order to use these tools, these generative AI tools,

in order to actually generate useful programs,

you mostly have to already know

how to write programs the old-fashioned way,

which is frustrating for a lot of folks,

but that seems to be the reality, at least right now.

Minute_Order4809 asks,

What is the best way of using AI while coding?

My first answer would be, are you sure you have to?

Double check, but if you've decided, yeah, I'm going for it,

the thing you wanna do is first, break down your problem,

whatever sort of shape that problem has,

into the smallest portion of that problem

that you can think of.

Ideally, this should be something

that's gonna be about maybe five-ish lines of code,

something like that, and then instead of writing it out

in sort of standard human language,

write it out in pseudocode,

so pseudocode is basically where you're describing,

this is exactly the thing that the computer's gonna do,

and then this is the thing the computer's gonna do,

and this is the thing the computer is gonna do,

and it basically looks like writing

in a programming language,

except you're just not fussed about syntax.

You're not worried about if you're missing a semicolon

or if the indentation is right, that kind of thing.

Go ahead and feed that into your AI tool,

and then you have to have a concrete plan

for how you're gonna persuade yourself

that what comes out the other side is right.

Do you have 20 tests that you're gonna run?

Do you have a friend who can look at this code

and make sure that it's actually doing the right thing,

or if you are yourself a programmer,

are you gonna go through and make sure

that it's actually doing the right thing?

So have a concrete plan for how you're gonna check it,

or you know, just don't use it.

AdHistorical6271 is asking, Experienced developers,

what has your experience been with vibe coding?

Vibe coding is when we use one

of those large language models or something like ChatGPT

or one of the other tools built on top

of that same underlying generative AI technology

to generate a program,

instead of writing it out the old-fashioned way

by just typing a program in our programming language.

Vibe coding seems to work okay

if you are rewriting something

that has already been written many, many, many times before.

On the other hand, if you're trying to do anything new,

that's probably not gonna get you anywhere.

The best bet, really,

is to carve the problem up into teeny tiny chunks

and then sort of use your own reasoning

to actually do the program.

Actually, there's been some really interesting studies

about this that looked at sort of the differences

between whether it actually makes someone more productive

versus whether they perceive

that it makes them more productive.

It turns out, using an LLM-backed tool made them 20% slower,

but even after doing the task with the tool,

they all said they thought it had made them 20% faster.

ulteriorkid324 asks,

What does live coding actually look like?

So basically, anytime that you are programming,

you're probably doing it live.

I don't really know what the alternative is,

so you're probably doing it live, but usually,

we use this term specifically when we were talking

about doing it in front of an audience, like y'all,

so I'm gonna go ahead and do that right now,

and we're basically gonna use this as an opportunity to see,

what are some things you can do

with honestly a pretty short, pretty simple program,

but we're just gonna talk it through step by step?

So I'm now gonna pull up an editor.

We've got this tiny, tiny little program in here,

so we have this URL,

sort of an interestingly structured URL,

but it's the same kind of URL

that you might type into a browser,

and then we have some country codes,

and this one has a lot of them,

but then here, we have sort of a smaller list.

We can see USA, Mexico, Canada.

Let's start by just printing this out,

so let's go ahead and print your country codes,

and programmers love to start counting

at zero instead of one, but that is, in fact,

referring to the first item in the list,

and we will copy that a couple of times,

because we're gonna wanna print all of the items.

This is called tiny_map, so I will run tiny_map.

You can see it has printed out those country codes.

It's not an exciting program,

but maybe I want to actually use those strings,

those little pieces of text,

in order to modify that original URL,

so instead of just having the country code,

let's instead copy this.

Where it says USA in this sample URL,

I'm gonna go ahead and replace that

with the country code that we are trying to use.

Let's go ahead and pop that in there.

We wanna start with zero,

and again, we're gonna have to do the thing

of copying and pasting a couple of times.

Here we go, Python 3.

We are now seeing our variants of the URL.

We can see we've got the one that has USA,

we've got the one that has Mexico,

we've got the one that has Canada.

Well, we probably aren't that interested

in just printing out URL.

We are probably trying to actually do something interesting

with that URL, like maybe get some data back from it,

the same way we would if we popped it into a browser,

so let's go ahead and open something called a library.

Basically, if some other programmer

has made a bunch of little program snippets,

and they said to themselves,

This is gonna be useful for a lot of different people.

I'm gonna make it available, we would call that a library.

So I'm gonna go ahead and import requests,

so instead of print, let's now have requests.get,

and we'll go ahead and repeat that process

for all of these URLs.

I'm starting at this point, personally,

to get pretty bored of just retyping out

this same big long string every single time.

I'm starting to think maybe there's something

that could help me avoid doing all that copying and pasting,

maybe sort of automate for me the process

of doing some of this.

Let's get introduced to a loop.

A loop is gonna let us do something repeatedly

for a bunch of different items

that have some similar structure,

or for which we want to do the same kind of thing,

so for I in range.length of fewer_country_codes,

let's go ahead and do something.

Let's probably go ahead and do that request,

but I don't always wanna do it for the first item

in our country codes list.

I'm probably gonna wanna do it for the eighth item,

the zeroth, then the first, then the third.

Right now, we're not having anything printed out,

but I'm gonna show that this is, in fact,

going to run it for everything,

so I know that request is gonna give me back some JSON.

JSON is just one of those standard formats that we have

that lets us represent data in a way

that lots of different programs can understand,

so if you have a standardized way,

then your different programs can talk to each other.

So let's go ahead and print out the JSON

that we're getting back by running each of those requests.

Okay, big messy JSON, not super fun to read.

Let's add ourselves a couple little sort of separators,

just to make it a little bit easier.

We can run it again.

Okay, we are now seeing, these are split apart

according to which of the three items

they were associated with.

I'm looking for this life expectancy data,

and I know that this sort of particular part of the URL

is that, and I know that the particular part

that is going to tell me, in this JSON,

what we're actually gonna have as the value

is this numeric value thing right here,

so I'm gonna go ahead and pop that into the code

so that I don't have to just look through all of this.

Let's give this a name. What shall we call this?

We'll call this just the JSON, and then we can go ahead

and get out from the JSON whatever is the portion

that we are looking for,

so JSON, I think this is inside the value,

and we only want to get one item, this numeric value,

so let's call that something.

Let's maybe call that life expectancy.

So now I wanna go ahead and print out country code,

this value right here,

and we just have to make sure that we have stored it,

we've saved it, we've given it that name,

before we actually use it.

Let's print out both the country code

and the life expectancy,

and let's see if we're getting the data

that we're expecting.

Looks good.

We can see the life expectancy

for these three countries that we were looking at.

Okay, let's go ahead and actually save that data,

'cause maybe you wanna do something else with it later,

so let's make a new list.

This one will be empty, and we're gonna go ahead

and fill it with the data that we're grabbing

from these calls to the requests library

from going out to the web and saying,

Bring me back the data for this country.

Let's keep on printing it, too.

Let's also go ahead and add it into data,

so we will append to the data list,

and we'll go ahead and put in country code

and life expectancy.

Let's print out our data at the end of the process,

just to make sure that this is actually looking

like we're expecting it to look.

I'll run the program again.

Okay, we are seeing that data at the end.

What if we put it on a map?

Again, we're gonna wanna use a nice library

that someone has built for us,

so let's import plotly.express, and we'll call that px.

So now, instead of just printing the data,

let's also make a figure that represents the data,

so fig equals px dot, I think it's chloropleth,

and let's use our data, and now we're gonna have to tell it,

what are the locations,

and what are the things that we want to visualize in this?

So I'm gonna say locations, and I'm gonna have that be zero,

meaning it's the zeroth item in each of these pairs.

We can see that right here,

we can see country code is on the left,

so it's the zeroth item,

and then life expectancy is the oneth item,

or in the sort of more usual terminology

that you and I would use day to day, it's the second item.

So let's go ahead and say color equals one,

and once we have actually got that,

let's actually show the figure, so here we go.

We've got our program ready to go.

Fantastic, we can see our little map. Here it is.

It's got those three countries colored.

We probably are interested in doing it

for all the countries,

so I'm just real quick gonna go in here

and actually change which of these lists we're using,

so you can see that we've just been using

these fewer country codes, which just says the three,

but why not run it for all the countries, right?

The data's there, so let's go ahead

and use some country codes instead of fewer country codes,

and let's get rid of all these old, unnecessary lines,

and then we'll have our final program, so here we go.

It is gonna talk to the internet,

it's gonna collect the information

for all those different countries,

and after a few moments there,

I think it was a little under a minute, we've got our map.

It's got the data for a bunch of different countries.

HGMIV926 asked, How do I read code?

This is honestly an incredibly difficult question to answer,

because reading code is actually really hard.

It's not like when we're sitting down to a piece of text,

we're gonna start on page one, we're gonna go to page two,

we're moving this sort of linear manner,

that's not how we typically do it when we're reading code.

Don't take this advice if there's any chance

that your code might be malicious,

but if this code is not malicious, go ahead and run it.

Take a look at a part of the output

that you are interested in, you wanna follow up on.

Go figure out what part of that code

actually created that output,

and then start working your way back.

What were the outputs that came out

of some earlier part of the code

that ended up going into the process of making that output?

There are even debuggers that are specially built

to sort of help you work

through individual executions of code,

so one of my favorite kinds of debuggers that I really like

is called time travel debugging.

You've gone ahead, you've done an execution of your program

that you're interested in,

but maybe you actually wanna walk it back.

You wanna travel back into the past

to see what was happening before.

You can go ahead and do that.

If you then wanna travel ahead, you can do that,

thus time travel.

vidro3 asks, How do computers understand code?

I'm gonna talk us through it

with a specific concrete program.

I'm gonna show us how we get from something

that looks kinda like a computer program

that you might have seen places

all the way down to the ones and zeros

that you can then actually store in the machine,

and we'll draw the four stages that we take it through.

So this is gonna be just the input to this entire process,

so here we go, we've got one plus two plus four.

Now, the very first thing that needs to happen

is I have to figure out which portions of this

to treat separately versus together.

I'm gonna just do that by underlining,

so the left parenthesis is gonna be on its own,

the one is gonna be on its own, the plus sign, the two,

the right parentheses, the plus, the four.

You can see we have ignored these spaces.

We've got our left parenthesis, our one, our plus, our two,

our right parenthesis, our next plus, and our four.

This stage, what I've just drawn out,

that is called lexing or tokenizing,

because the things that you see in this list on the right

are the tokens, so the next thing we're gonna wanna do

is turn this into something that we can actually sort of use

to understand something about the structure of this program,

so here, at the root of something

that I'm gonna call a tree,

we're gonna have the addition operator,

and this is gonna be the operation

that's gonna actually happen second,

because what we wanna do is we wanna make sure

that that one and that two that we're adding together,

we can see that those are in parens,

we actually wanna do that first,

because that has been grouped,

and we'll have a one on the left and a two on the right,

and then what we have on that last branch there

of the top add is gonna be that four.

Now, we can start to see

that there's some structure happening here.

We can see that sort of the one and the two

are gonna be grouped together by some operation,

and then whatever we get out from that operation,

that's gonna be grouped together with the four,

but actually, a lot of folks know

that what goes into the computer

eventually has to be ones and zeros,

and there's no clear way necessarily, at this point,

to turn this into ones and zeros,

so now we're gonna turn it

into something called instructions,

and instructions are basically just gonna be the things

that the processor knows how to handle, so here we go.

We're gonna go ahead and write out move one,

'cause that's the first value that we're dealing with,

into R8, one of the slots that the computer has available,

and then maybe we'll move into R9, another slot,

the value, two.

We now have everything we need to do

in order to run our first addition,

so let's go ahead and do an add instruction,

and we'll go ahead and add together what we've got

from R8 and R9, and that is gonna put that value inside R8.

So now, let's go ahead and move that four into one of these,

so we're no longer using R9 anymore

for the thing we were previously using,

so let's go ahead and move into R9 the value four,

and now if we do add R8, R9,

we should get the result of the entire program in there.

And then this phase, where we're actually taking

that nice, structured representation of the program

and turning it into instructions,

that is actually called code generation,

but at some point, it actually has to turn

into ones and zeros, so let me go ahead

and highlight some common structure that we're seeing

across these instructions.

We can see that there's sort of this thing,

and then there's this thing, and then there's this thing,

and it turns out that we have a scheme

for turning each of these into a binary number,

and then we do the exact same process

for all of those instructions,

and finally, what we have is just ones and zeros,

so now, I'm gonna turn to the computer.

All right, so here we in something called x86-64 Playground.

This is just a website. You can visit this on your browser.

I have typed in the instructions

that I was drawing over here on the iPad,

and so we're now gonna get to see what it actually does

to representation of the computer state

when we're running through these instructions.

So here we go. We start with that first move instruction.

You can see that, over here in R8,

we now have the value one,

so let's go ahead and run the next step.

Fantastic, we can see that now, inside R9,

we've got that two value.

If we keep going, we're now gonna see

that we've done the addition,

and the output from that addition, the value three,

that now lives inside R8.

Fantastic, one more. We've got moving the four into R9.

It's okay for us to reuse R9.

We're not overriding anything we're gonna need later,

so it's totally fine.

We can go ahead and get that value into R9,

and then one more,

and we can see that we've done that last addition,

and we've got the final output, seven,

represented inside R8, and that is how the computer

understands the code that you write.

That's it. We have run out of questions today.

I hope y'all have learned something new.

I hope you're excited about programming languages

and maybe even about compilers.

Until next time.

[upbeat music]

Up Next