DAVID MALAN: As folks finish
signing up, let me bite off
a couple of the smaller questions here.
So one of the questions was, what is
a Content Delivery Network, or CDN?
So CDN really is a
generic term describing
servers whose purpose in life is to
deliver content, which simply means
they are web servers that have hard
drives or some other form of storage
that people put files on,
generally static files,
and by static I mean unchanging.
You write them once.
You upload them.
And it's an image.
It's static text.
It's not a dynamic interactive
website necessarily.
And the CDN's purpose in life
is just spit out those files,
when requested, to browsers and do
it ideally in a very efficient way,
possibly by using a lot more RAM
than might be typical just so that it
can respond very quickly to requests.
And Akamai initially built its
business on this kind of idea.
Amazon and Microsoft and Google
all have similar services as well.
So there's not all that
much that's fundamentally
different from servers
with which you're familiar,
but they tend to be global as well.
So using various DNS tricks
or load balancing tricks,
do they make it easy to
distribute your data globally
because there will be different
servers in different countries
or continents for different users.
So we, for instance, distribute a lot
of our course videos via Amazon's CDN
so that we can push
it out without having
thousands of people come to Harvard.edu
servers to try to download the same.
And indeed, when we tried that
latter approach years ago,
the servers buckled under the load
for some of the largest of files.
Griff?
AUDIENCE: I was just
going to say [INAUDIBLE].
And many of the locations that we try
to [INAUDIBLE] are blocked [INAUDIBLE].
So have CDN or having [INAUDIBLE].
Otherwise videos will be blocked.
I'm sure you've had
this experience before.
[INAUDIBLE]
DAVID MALAN: Yeah, absolutely.
So that's a good work around for
when popular consumer services,
like YouTube, are indeed blocked.
And even Netflix you can think
of as a CDN of some sort.
And in fact, to address some of
that same issue for cost reasons,
though, or for bandwidth reasons,
they have, at least they used to have,
a Netflix appliance that you could
actually have ISPs installed locally.
So that if Comcast, for instance, was
getting tired of having the same movie
files, for instance, downloaded over for
their network from some other network,
or if this is just
burdening their network,
they could actually cache the files
locally, which is some form of CDN
as well.
So that users end up talking to
that local cache server instead.
The security of the internet
of things-- so just to clarify,
what does the world mean when they say
Internet of Things these days-- IOT?
It's kind of the buzzwords du jour.
Alicia?
AUDIENCE: [INAUDIBLE]
DAVID MALAN: Yeah, for
some reason, my go-tos
are always the things
in the kitchen, too.
Yeah, it's like putting everything on
the internet-- Nest thermostats, which
I do have and which I'm a fan
of, and other such devices,
like your refrigerator, if
it's got a little touch screen,
and the smoke alarms, which that did
not go over well for Nest initially.
Bad to release a product
where safety is at stake when
you have buggy software in it.
People go up on that fiasco.
But internet of things
really just describes
putting more things on the internet.
And I think the question earlier was,
can we speak to the security of it?
I dare say I'm fairly pessimistic
when it comes to this.
I think we humans have made the exact
same mistakes in the world of phones
that we did years ago with PCs and Macs
and desktop computers more generally,
where we don't write very good software.
And there's innumerable articles
out there about various devices
that are still shipping with
default passwords of admin
or password or no
password, or some engineer
has hard coded something
into a home router,
and no one thought to disable that.
And the list goes on and on.
So I dare say the internet of things
won't be very good at security
because we humans haven't
gotten all that much
better at these kinds of issues.
But it's interesting to consider the
sort of new threats that are imposed.
In fact, I remember it was a
wonderful gift from a friend of mine,
when I had first gotten a
couple of cats years ago.
He kindly gifted to me this cat feeder
that itself was like electronic.
So if you travel, it can
feed the cats automatically.
And it had this audit feature,
whereby it had a little webcam built
in so you could actually see the food
bowl, which is good for reassurance
that the thing's not jammed
or you know call a neighbor
if the cats aren't actually getting fed.
So it's a compelling
use case for a camera.
But the way it worked was in
order to see your live webcam
feed from your cat food feeder, it
was going through some server abroad.
So you would go to some random
website dog come in whatever country,
and that's how you would
watch your live feed.
So it wasn't that you were
connecting to your home's IP address,
and you weren't running a
web server in your home.
Rather the camera was transmitting this
data, similar in spirit to Dropbox,
to some central server.
And if you want to see those bits,
you log into that central server
as well, which means any
creepy employee of this company
has literally a window into my home.
So it creeped me out,
and I couldn't do it.
So I returned it.
And it's gotten me thinking ever
since then about home security
cameras, things that are on the web.
Like if you are visiting your
own home security camera's data
feed on someone else's website,
they too have access to it.
And so these are particularly
concerning things.
Avi?
AUDIENCE: [INAUDIBLE]
DAVID MALAN: What's that?
AUDIENCE: [INAUDIBLE]
DAVID MALAN: No.
Because it had a wide enough field of
vision where it would capture the bowl,
but also anything over there.
And maybe just at waist
height or whatnot,
but it was just like
unnecessary information for me
to just be handing over
to someone 24/7, I felt.
AUDIENCE: [INAUDIBLE] Smart TV.
DAVID MALAN: Yeah.
No, I'll admit to being
paranoid enough where I do not
connect my smart TVs to
the like the internet
because it creeps me out
that one, many of them
have cameras now for what I
think are stupid features,
like waving your hand to change the
channel or the volume or whatever,
which can't possibly
work reliably in 2016.
So there's that.
Samsung took a lot of
heat a year or two ago now
for their smart TVs,
in whose privacy policy
it was disclosed-- it was
something along the lines of-- it
was a brilliant wording.
It was like we recommend that you not
have personal conversations within view
of this TV.
It was something like that,
where they were disclosing it,
albeit not on the box.
It was in like the tiny,
little printed brochure.
Because for the TV to be
able to respond to this
or to be able to respond
to your voice a la "hey,
Siri," it's got to be
listening all the time.
Alexa, from Amazon, creeps
me out for the same reason
because if its constantly
listening, which
is billed as a feature, well, who
all knows what else its listening to.
And the fact that watching TV in bed
or on the sofa, like I don't want this
like constantly projecting whatever
it sees onto the internet and even
the voice stuff too.
So I try to disable all of that.
And even here, we humans are bad.
Just two years ago, there
was this wonderful article
about Samsung's smart TVs which
were being so incredibly dumb.
They were transmitting their
data on TCP port 443, which
recall is the secure port for HTTPS,
but they weren't encrypting the data
on that port.
So it was a dummy engineer
sort of knew that, oh,
you're supposed to run secure
traffic through port 443
but didn't realize you also
have to enable encryption.
Like it's not enough just to use that
number on your virtual envelopes.
And so here, too, all of the data-- and
some researcher somewhere noticed this.
Like all of the voice
commands or whatever
it was were leaving the TV
unencrypted, so that any creepy person
in your Wi-Fi network or in with
physical access to your network
could see what's coming out of your TV.
So, yeah, internet of
things is frightening.
It just means putting
more bad buggy software
in hardware in our physical presence.
So be aware and be
mindful of these things,
because I do think we can
exercise some judgment.
So if you think that baby
monitor's a great idea
to put over your child
all the time, realize
that those bits might
be getting transmitted
to some creepy company or some third
party, and maybe that's not really
a threat because who's
really going to care?
But if the server is
compromised and now you
do have someone else
having eyes into your home,
this is going to become
all the more common.
AUDIENCE: [INAUDIBLE]
DAVID MALAN: Yeah, this is
kind of the next frontier of--
AUDIENCE: [INAUDIBLE]
DAVID MALAN: And this one,
I daresay, is inevitable
just because all it
takes per our discussion
yesterday for one association
of you with that history
to be made before you can reconstruct
the entirety of your history, right?
If you've been photographing
someone for years,
but you've never figured
out who they are,
all it takes is for one time
for someone to capture a photo,
associate it with their identity,
and now we can look back in history
and be like, oh, we have these other
thousands of photos of this individual.
AUDIENCE: [INAUDIBLE]
DAVID MALAN: Yeah, now
you can check their face.
AUDIENCE: [INAUDIBLE]
DAVID MALAN: Yeah, and it
doesn't help that most of us
are proactively tagging ourselves
on Facebook and other social media.
So we are creating this
database as we speak.
Yeah, no, this one I unfortunately
think, pessimistically, is inevitable.
We're not going to be able to avoid
it, especially when the cameras are
being put-- I mean, the
UK's had this for years.
But it's really just for recording.
Now facial recognition takes
it to a whole new level.
I'm already impressed
too how good Facebook's
getting at like tagging friends, when
even their head is slightly askew
and it's not a great shot.
I mean, it's getting better and better.
So beware.
Some of this stuff, I
think, is in our future.
Speaking of, how do you
write stuff like this?
So programming-- so what
I thought we'd do here
is really just give everyone
a taste of what programming
is, albeit in a playful context,
using a graphical program that we
use in our undergraduate
class called Scratch.
This is a graphical environment that
you might have gleaned some images of,
as you registered for an account.
Even though it's playful and
technically meant for ages 12 and up,
it is actually wonderfully
representative of a typical programming
language-- a certain type of
programming language called a procedural
or an imperative programming
language-- and as such,
it's very similar in spirit to Java,
JavaScript, Python, PHP, Ruby, C++, C#,
any number of languages that
you might have heard of.
But it does it in a much
more playful context.
But it'll allows us to
talk about examples of code
without actually seeing
more arcane code.
For instance, just to give
you a sense of context,
if I wanted to write a program
in a language called C,
I would open up a text editor like this.
And this happens to be
a program called Vim,
but it could just as soon be a
program like Text Edit or Notepad.
All you need is a text editor.
And I'm going to type some magical
incantation like this in this language
called C-- int main void.
And then I'm going to have some curly
braces and now a print f hello world,
and now I'm going to
say, let's say, return 0.
So some of you might recognize
symbols and syntax like this.
But for those who don't,
you can perhaps guess
what this does, even if you just
ignore anything you don't understand.
Take a guess as to
what this program does,
if you've never programmed before.
Take a guess?
AUDIENCE: Writes hello world.
DAVID MALAN: Yeah, it
prints hello world.
I don't really know what return means or
int main void or include standard io.h.
But printf, albeit,
print sounds familiar.
Hello world looks like a sentence.
So let's see what happens.
Now, this is a file called hello.c.
And to run it, I would normally
on my Mac or PC double click it.
But this is a text-based
environment so I can't do that.
I actually have to run it.
But to run it, I first have to make
it or build it with a compiler.
So GCC, Gnu Compiler
Collection or a GNU C Compiler,
is a program that has just turned
hello.c into the equivalent zeros
and ones that my Intel
CPU you will understand.
And if I run this with
this magical incantation,
a.out is just the silly
default name for my program.
Enter, indeed, as was
posited, print hello world.
So not all that interesting.
Let's rewrite this in Java,
so hello.Java, class hello,
public static void main string args.
Java's even stupider when it comes
to starting the writing a program--
system.out.print line hello world.
OK, that is the equivalent
program in a language called Java.
It's a little different.
But you can kind of
glean some similarities.
There's still curly braces.
There's the same string hello world.
There's the word printf,
although I could actually
do this with-- print line would
be a little more common in Java.
Class is a new word.
It hints at features called
object-oriented programming, which Java
offers, as do some other languages.
But this is generally what
a text-based language does.
Thankfully, there's
even simpler languages.
So if I want to write a program
in a language called PHP,
I can simply do print hello world,
and this one is now done in PHP.
And you can do this in
Python, Ruby, anyhow.
So there's many different languages
in the world of programming,
much like there are many
different spoken languages.
And much like we could communicate
in English or Spanish or Japanese
or any number of other
spoken languages, so can you
write programs that at the end
of the day do the same thing.
These programs all print hello
world, but you express them,
you write those programs
in different ways.
So why?
write I can understand that there's
thousands or millions of years
of history over which languages evolved
independently in different cultures
and kind of mutated over time.
But we humans also invented pretty
recently programming languages,
relatively speaking.
Why is there not one programming
language with which you write software?
AUDIENCE: [INAUDIBLE]
DAVID MALAN: Competition?
In what sense?
AUDIENCE: [INAUDIBLE]
DAVID MALAN: OK so people might have
wanted to make money off of this--
so make a better language
than someone else.
What might it mean to be a better
language or a competitor language?
Yeah?
[INAUDIBLE]
AUDIENCE: [INAUDIBLE]
DAVID MALAN: Yeah, which is similar
in spirit to the idea of competition.
People decide have decided over
time, hey, I can do this better,
or we can do this better.
And better might mean different things.
It might mean that your software at the
end of the day runs faster than someone
else's.
It might mean that your software is
easier to write than other languages.
And it might not be a
competition in a business sense.
A lot of languages have
been developed by academics
because we think we can do a better job
at improving upon previous languages.
And there are different
approaches to languages.
One of which would be called an
interpreter versus a compiler.
And what I just did a moment
ago was to write a program
in C, my very first program.
And I ran it through a
compiler, that thing called GCC.
And what that means in real terms
is that you write a program that
looks like this in English-like syntax.
It is definitely cryptic,
but Katy was able to glean
what it did-- print out hello world.
You run it through a compiler.
And then at a little bit of
an oversimplification, what
comes out of that is a whole
bunch of zeros and ones
that the Intel CPU understands.
And the compiler is specific
to the CPU so that if you have,
back in the day, a Mac or a PC
or some other kind of device,
the compiler would spit out zeros
and ones that the Mac understands
or the PC understands or the
Linux computer understands.
It's also tied, in part,
to the operating system,
not just the underlying CPU.
Most consumer computers
these days have Intel CPUs.
So they're using the
same underlying hardware,
but the operating system is certainly
the different across different types
of computers-- Macs, PCs, and the like.
And so this is generally
what happens here.
And what does it mean
for Intel to be inside?
Well, among the things that
Intel CPU, or any CPA does,
is it has a certain set of
instructions that it understands.
And I had proposed yesterday
they're pretty basic instructions,
like addition, subtraction,
multiplication, move something
from here over here in
memory, load something
from here to here in memory--
very simple operations.
And in the interest of
abstraction, let me just
stipulate you can get from
admission of subtraction
and multiplication all the way up
to Photoshop and YouTube and playing
videos and the like.
There's a layering there.
But a compiler is necessary
to go from something
that's pretty human readable, if
cryptic looking to the uninitiated,
to those zeros and ones.
An interpreted language, by
contrast, rather skips this step.
And actually I didn't quite leave
enough space on the board here,
so let's-- CPU, from there to there.
An interpreted language might look
the same-- or rather in a language
that you're planning to interpret.
You run it through an interpreter.
And at the risk of
oversimplifying here, too,
let me just say that it essentially
gets run directly on the CPU.
There's some stuff happening.
Really, what the interpreter is
doing is reading your code top
to bottom, left to right.
And any time it sees an instruction
it recognizes, it inside of it
has zeros and ones that
the CPU understands.
So the interpreter is
what's running on the CPU,
and it's interpreting
your program line by line.
By contrast, when you compile
a program with a compiler,
it's your zeros and ones
that are running on the CPU,
and that's a reasonable distinction.
So historically, languages like C and
C++, older languages, were compiled.
And a lot of more modern
languages tend to be interpreted.
Technically, you can compile or
interpret any type of language.
It depends on if the software
exists, but they correlate
with certain historical traditions.
So c and C++ have tended
to be compiled languages.
More modern languages, like Python and
Ruby and PHP, have been interpreted.
Java is kind of a weird middleman,
whereby you do compile it,
but you compile it not
into zeros and ones per se,
but into something called byte codes.
And byte codes are instructions that
the Java virtual machine understands.
So among Sun Microsystem's
contributions the world years ago,
when they invented Java, is
instead of assuming an Intel CPU,
they essentially created
their own CPU in software
so that their Java code could run
on Macs, on PCs, on Linux computers.
But you had to have the Java virtual
machine software, the Java Runtime
Environment, running on your computer.
But that's still used today
in different contexts.
But this is a reasonable type
of categorization-- interpreted
and compiling your software.
So let's just do a quick laundry
list of languages, if only
to get it out there so as to dispel
any confusion as to what languages are.
So C, C++, C#, take it from there.
What else have we heard of?
AUDIENCE: [INAUDIBLE]
DAVID MALAN: Go, Java, I
heard JavaScript, I think.
Fun fact-- not at all
related to one another.
JavaScript came after,
and the marketing people
decided that, oh, Java's
so trendy, why don't we
call our language JavaScript,
essentially dupe people
into thinking they're related
and get this one popular too.
Turns out it became popular
but has no relation to Java.
AUDIENCE: [INAUDIBLE]
DAVID MALAN: React would be a
framework not a language per se.
AUDIENCE: [INAUDIBLE]
DAVID MA LAN: Python,
AUDIENCE: [INAUDIBLE]
DAVID MALAN: Ruby--
I am actually amazed.
We're actually doing these
alphabetically accidentally-- amazing.
Python, I heard Ruby.
I can only take languages
starting with S or later.
AUDIENCE: SQL.
DAVID MALAN: SQL, we'll
talk more about that later.
AUDIENCE: [INAUDIBLE]
DAVID MALAN: Perl-- oh,
dammit, you broke my system.
Perl.
AUDIENCE: [INAUDIBLE]
DAVID MALAN: No, so PHP--
Django is a framework.
So we'll talk about that
later-- not a language.
And we'll distinguish
what that means later.
AUDIENCE: [INAUDIBLE]
DAVID MALAN: What's that, VBA?
Yeah, Visual Basic.
Yeah, so VB or VB Script.
AUDIENCE: .NET.
DAVID MALAN: .NET isn't
a language per se.
It's a collection of stuff
that you would usually use,
like Visual Basic or C# with, so I'd
put that into the framework category.
Other languages come to mind?
AUDIENCE: [INAUDIBLE]
DAVID MALAN: Swift is
a new one from Apple
designed to make iPhone programming
and Mac programming easier.
Objective-C is the earlier language
that they used for many years
on Macs and iPhones.
AUDIENCE: [INAUDIBLE]
DAVID MALAN: Julia, oh,
I don't know that one.
This?
AUDIENCE: [INAUDIBLE]
DAVID MALAN: OK, nice.
Others?
AUDIENCE: [INAUDIBLE]
DAVID MALAN: Yeah, so
BASIC, Pascal, COBOL--
we used to capitalize
all languages-- FORTRAN.
It's a lot, and it's
kind of overwhelming.
And many programmers
will know many languages,
I daresay far more than
a typical human would
understand spoken or written languages.
So
Why is that?
Well, I think Anissa made the claim
earlier that different languages are
better for certain things.
And that's indeed the case.
And most anything we discuss today
we'll be a sweeping generalization
because there's a lot of
religiousness in the technical world,
where people will bring to the
table their own bias or preferences
or experiences.
And this too is an important
thing to realize, especially
when hiring technical folks or
discussing things with engineers.
They're going to bring their
own solutions to the table,
and it's perfectly acceptable if
someone is recommending something
just because they know it well,
they've used it well, they know the ins
and outs, because that alone can be a
positive and save cost and so forth.
But it can also be a downside if
someone's knowledge or expertise
is dated, if they're using
the wrong tools for the job.
For instance, like back
in the day, I first
learned web programming
in a language called Perl.
And this was 20 or so years ago.
No one really uses Perl for
web programming anymore.
You can.
It certainly still works,
and they've continued
to modernize it and add features.
But just no one really does it, and so
it would be a strange choice but not
an indefensible one.
Using is C possible for making websites.
That would be very,
very strange these days
and harder to justify because
you have to write so much more
code in a language like
C to get real work done,
because it just wasn't
designed for that.
By contrast, PHP was designed
for a web, and it was actually
designed fairly sloppily initially.
But it made web programming so, so easy.
And one of the reasons
it's been so accessible
is because it's been so deliberately
intertwined with web development.
More recently has Python and Ruby
gotten popular for web development,
but neither of them were
designed for the web
per se in quite the same way as PHP has.
So per our upcoming chat later, there've
been a lot of libraries or frameworks
that have emerged.
People have written code
to make your life easier
if you want to use Python
or Ruby for web programming.
Rails, for instance-- Ruby on
Rails is a popular expression,
and it describes a
framework that you allows
you to use Ruby for web programming.
So the short answer is, it depends.
And if had to make a bold
claim for web programming
these days, which will be our
focus later this afternoon,
JavaScript is prerequisite
because, thank god,
there's only like one language that you
can really use on all browsers' client
side, more on that later, but running
inside of the confines of a web
browser.
So you pretty much only
get JavaScript there.
But also super popular on the back end,
so to speak, would be Python, Ruby,
PHP, C# in the Windows
world, and Java, I would say.
And that's changing.
And even that is just
kind of current trends.
Go is increasingly popular, and
other languages still could be used.
And there's some not
even on the list here.
So these are really just tendencies.
[INAUDIBLE]
AUDIENCE: [INAUDIBLE]
DAVID MALAN: No.
So per yesterday, I would emphasize
that HTML is a markup languages.
It's only about aesthetics
and structuring of data.
It, doesn't have the
ability, as we'll soon
see, to express yourself logically.
And there's a couple little
exceptions to that in CSS.
But no, it's not a programming language.
You could not write-- well, you could
make a web page that says hello world.
You cannot write a program that runs on
the CPU of a computer that says hello
world with HTML.
AUDIENCE: [INAUDIBLE]
DAVID MALAN: That would be a-- well,
it's slightly apples and oranges.
I know what they mean.
Java is a horrible language for making
web pages because it never caught on.
It was designed as a wonderful idea.
You could write your software in Java.
You could then embed what's called a
Java applet inside of a web browser.
The problem is that browsers never
really supported this very well.
Apple has had a little
fit with Oracle, and it
doesn't make it easy to even
use Java on Macs these days.
And it was always damn slow
to load a so-called Java
applet in the web browser.
It wasn't necessarily as accessible
as native browser support was.
So Java applets are dead, so
far as the web are concerned.
It has been the case for some time.
So if there was legacy software written
in Java, not a good thing for the web
anyway.
Using HTML 5 technically refers only to
the language we talked about yesterday.
But it's also arguably an umbrella
term for HTML 5 and CSS and JavaScript.
And that would make sense.
So they're kind of oversimplifying
when they say that.
But that would be the
casual way of saying it.
Good question.
Yeah?
AUDIENCE: [INAUDIBLE]
DAVID MALAN: Yeah, Scala,
too-- also very popular,
especially with
data-driven applications.
But in short, there's not
necessarily one right answer.
But there probably are
some wrong answers.
And the way to glean
what's appropriate here,
especially if you're vetting a proposal
from some engineers or your trying
to decide whom to hire, is
frankly, especially if you're
relatively non-technical, is just
ask the advice of someone technical
you know to vet their resume s maybe
Google around as to the technologies
the person or persons
are proposing to bring
to bear on the solution,
just to get a sense of
whether or not they're
making good decisions.
And we'll see this afternoon, there's
any number of other lower-level design
decisions independent of
language that can also
kind of hint at the quality of someone's
thought process or experience as well.
Fortunately, in the phone world-- so let
me actually clarify a couple of these.
So let me propose that back end,
the back end, front end, back end,
back end, back end, and then M for
mobile, and also Java would be mobile.
So thankfully, in the world
of mobile applications,
you pretty much only
have Swft-- you only
have Swift and Objective-C on iPhones.
Or in the world of
Android you have Java.
And those are by far, the
biggest phone providers,
so those are kind of the only
two scenarios to consider today.
However, there's a middle ground.
You can implement mobile applications
using HTML 5 and JavaScript and CSS.
And in fact, a common
strategy initially, especially
for startups who don't
have the money or the time
or the expertise to develop not only an
iPhone application and also an Android
application and maybe Windows
Phone or a couple of other things,
is instead not to write any code
in Java or Objective-C or Swift,
but instead implement essentially
a mobile-friendly website
and then use third-party
software that gives you
a tiny bit of Objective-C code
or Swift code or Java code.
But then you follow their
instructions and you
embed your web-based application inside
of a tiny bit of Objective-C, Swift,
or Java code that someone else wrote.
You run a special command that creates
for you a native iPhone or Android
application that you can upload to
the App Store or the Google Play Store
and so users can actually download
it or even pay for it in the store.
But really that's just giving
you a big rectangular region
in your app, the contents of which
are actually just a web page.
So the upside of this is you don't
have to know any of these languages.
You can do all the
stuff we did yesterday,
plus a bit more when we talk
about JavaScript layer today.
And you can build it
once, literally, and it'll
work on all different platforms.
So the upside of that is obvious in so
far as you now need no expertise here.
You also don't need to
hire twice as many people
to develop twice as many
apps for iPhone and Android.
But what's a downside perhaps?
Why doesn't everyone do this?
Why are these Ms even on the list?
Yeah, you can't quite
do as much cool stuff.
So, for instance,
web-based applications tend
not to have as much access
to the hardware itself.
So if a web-based application
wants to know your location,
for like a map-based
tool, GPS-based tool,
the user is going to
be forcibly prompted,
hey, this web page wants
to know your location.
Is that OK?
You might not want to
allow that experience.
That's not a great you US, or
user experience, mildly annoying.
You might not have physical
access at all to the camera.
Like a web page or a
web-based application
can't necessarily turn on your camera.
It would be a little creepy
if you visit a website
and suddenly your camera turns on.
So there's those kinds of
defenses mechanisms in place.
The frameworks I alluded
to earlier that allow
you to wrap your program
in someone else's code
and create the illusion
of a native application
sometimes do give you access to
the hardware, but not all of it.
And it tends to be a little slower
to run web-based applications.
Facebook's mobile app
initially was web-based.
And if you use it at all, you might
have forgotten how slow their phone
app originally was.
And that was because it
was really just a web page.
So when you clicked a link, it
was like reloading more content.
It wasn't native.
So native applications, so to speak,
written in these three languages,
just tend to feel zippier.
They tend to fail
faster, more performance.
And they're much, much, much better
for games and such using native.
Native means written in
one of these languages.
And web app would be written
in HTML, JavaScript, and CSS.
Yeah?
AUDIENCE: Is the big
picture [INAUDIBLE]?
DAVID MALAN: Define big picture.
You mean the total landscape?
AUDIENCE: Yeah, total landscape.
This right here [INAUDIBLE].
DAVID MALAN: Yeah, it's bigger.
Hundreds?
I mean there's probably some that
are not on the Wikipedia page
I'm about to pull up to
try to overwhelm you.
Oh, here it is-- list of
programming languages.
So those are the A's, the B's, and there
is one called B, which came before C.
Here's the D's.
Here's the landscape.
If I can punt to a Wikipedia answer, but
most of these are fairly specialized,
outdated, silly.
Pizza language-- I don't
even know what that one is.
R is popular.
We could have tossed that on the board.
That's popular for data
analysis stuff these days.
And there's some silly things--
Unreal scripts, presumably
for a gaming engine.
Very few Z's and Y's,
so that's where you
want to go if you want to come
up with a new name perhaps.
So that's more complete
landscape, and I'm
guessing there are some
missing from there still.
So you have all of these
ingredients, all of these languages.
What does it mean to be
a programming language?
What are some of the basic constructs?
Well, at the risk of being-- let's
see how might we implement this?
Yesterday's example of the phone book.
Let's writes that program.
So recall that I was
searching for Mike Smith,
and I wanted to somehow find
Mike Smith in the phone book.
Let's see if we can't
translate the human intuition
we had for our third algorithm,
the fastest algorithm,
into something code-like.
And indeed a language, not on the
board because it doesn't exist,
is called pseudo code, and this is
just arbitrary English-like syntax.
There is no standard for it.
But it just should be roughly
intuitive and human readable to anyone.
It's no special syntax for this.
There's no curly braces or any of that.
So what might have the first step been?
Pick up phone book.
What's the second step from yesterday?
Looking for Mike Smith.
Flip pages?
OK, so let me say this feels
way too vague and abstract.
So let's undo.
And that would seem to induce
an infinite loop, if you will.
Flip pages, what does that mean?
I kind of do that endlessly.
We have to be more precise now.
Half pages-- so OK.
So how about open, let me just
say, to middle of phone book.
That feels reasonably precise.
We could then really be
nit picking and be like,
what do mean open the phone book?
But open to the middle of
the phone book, then what?
AUDIENCE: [INAUDIBLE]
DAVID MALAN: So look at pages,
decide if name to left or right
feels like a reasonable
way of expressing it.
And now I have kind of a decision point.
These are all instructions
or statements,
or I might call them functions.
These are actions.
Now I have to think.
What's the question
I need to ask myself?
AUDIENCE: [INAUDIBLE]
DAVID MALAN: Yeah so
is Mike Smith on page?
If yes, then call Mike, for instance.
Else, if no-- and actually, let me
try to simplify this because I'm
being unnecessarily verbose.
Let me change this to if
Mike is on page, call Mike.
Else, if Mike is to left-- so now we
can kind of clean things up into cases,
if you will, or forks in the road.
If Mike is to the left,
what do I want to do?
AUDIENCE: [INAUDIBLE]
DAVID MALAN: Go left, OK.
So how about tear phone book in half.
And now search left half for Mike.
How do I search the left half for Mike?
Well, what's kind of interesting is I
already have an algorithm for search.
And I could clean this up.
There's different ways
of expressing ourselves.
But what I've just highlighted in
blue is exactly the same algorithm
that I need.
So let's stipulate for today that
when I say search left half for Mike,
that is sufficient detail.
And we can clarify this as follows.
Back in the day, languages like
BASIC, one of the earlier languages,
used to number its lines.
And so let me just go ahead and number
these lines for discussion sake.
Oops, that's a bug.
How about keep left half.
Go to step two, to be specific.
So that seems to induce the sort
of cyclical behavior that we want.
What should step nine be?
AUDIENCE: [INAUDIBLE]
DAVID MALAN: Keep right half.
Good.
11, go to step two.
And is that it?
AUDIENCE: [INAUDIBLE]
DAVID MALAN: Yeah, we
should probably add that.
So end-- and actually, this is a good
example of now I've created a problem.
Thankfully, in modern languages
you don't number your lines,
so you don't have to worry about this.
But for the curious or
if you ever remember,
the language BASIC years ago used
to have this convention where
your first line of code would be 10.
Your second would be 20.
Your next would be 30.
Your next would be 40.
Why might that have been?
AUDIENCE: [INAUDIBLE]
DAVID MALAN: Yes, so when
you screw up, you actually
have 9 mistakes you can make before
you have to start re-numbering things.
So that was one approach years ago
Yeah, we should probably have an end.
How about, we'll cheat, then end,
just to cram it in there for now.
But there's one case
I'm not considering.
There's a fork in the
road I've not addressed.
Yeah, Grace?
AUDIENCE: [INAUDIBLE]
DAVID MALAN: Yeah, so else if Mike
is to right, else if Mike is on page,
call Mike.
So I kind of need-- and
it's a little non-obvious
based on how I've written it
how I weave this logic in.
So I'm going to cut a little bit
of a corner and say else if out
of pages, give up or something.
And I say I'm cutting a
page because I can't tear.
I should have it up here, right?
Because I can't tear the phone book
in half if there's only one page left.
But let's assume that
the spirit of this is
to capture all four
cases which we now have.
Otherwise there might have
been undefined behavior.
And indeed, if you've ever
been running Mac OS or Windows
software, where like you suddenly
see the stupid beach ball just
spinning and spinning, or the program
crashes, or it hangs-- yesterday
we proposed that if it's
just hanging or slowing down,
it might be because of
virtual memory and swapping.
But if it seems like it's not
working correctly, not just slowly,
it might be that someone
didn't anticipate a situation.
And programs will crash if
they encounter, for instance,
the equivalent of like
an out-of-service branch,
and there's no code there to handle it.
It might just crash because
you haven't anticipated
a scenario like that last one there.
What if Mike's not in the phone book?
So this is just pseudo code.
And we could have written
this in any number of ways.
But it rather captures
the spirit mechanically
of what we wanted to do yesterday.
So now let's transition
to a sillier but just
as real environment for programming
called Scratch, as follows.
I'm going to go here,
and we'll give everyone
a moment to play around in a bit.
But let me give a couple
of examples first.
This is Scratch's
programming environment.
And there's four main areas.
There's the stage up here,
this big white rectangle,
where this cat named Scratch lives.
There is down here the Sprites
Palette, so you can actually
have multiple characters.
You can change Scratch to
a dog or whatever else.
There's this palette of menu options
in the middle which are puzzle pieces.
Each of those puzzle pieces
represents a programming concept.
And on the right is the scripts area,
where you actually drag and drop
these puzzle pieces.
And notice at the top of
the stage here, there's
this green flag and the stop sign.
Those mean go and stop respectively.
And that's how we're
going to run our program.
And so what's nice about Scratch is
that it very quickly lets us get up
and running.
In particular, there's these
categories of puzzle pieces up here.
I'm going click on the Control
block-- no rather, the Events Block.
And I'm going to drag and
drop this one anywhere I want.
But I'm going to keep it
nice and clean and just
start in the top left-hand corner.
And notice the says one
green click flag clicked.
And notice it's got a little nub
to connect to other puzzle pieces,
and I'm going to go to Looks, and I'm
going to choose this one, Say Hello
For Two Seconds.
But notice these white
boxes are editable,
so I'm just going to say Hello
World, let's just say for one second.
And now watch the cat on the
left as I click the green flag.
I've programmed.
Now it's a simple program.
But it's the Scratch equivalent
to the Hello World program
we just did a moment ago.
So this isn't all that interesting.
What might we like him to do instead?
Well, let me, how about, do
something again and again?
So how about the repeat block.
And notice that I can
disconnect these things.
And even though it doesn't look
like anything fits in there,
it sort of magnetically
wants to go in there.
So I can let it snap into place, and
now I can let this snap into place.
And now just because I'm going to
have him say hello world 10 times,
click the green flag.
Hmm, what's going on?
this as expected?
AUDIENCE: [INAUDIBLE]
DAVID MALAN: He's not pausing.
But that's what I kind of hoped for.
But I haven't been
precise enough, right?
Because if he's saying
hello world for one second,
but then immediately it's doing it
again and then eight more times,
I never told him to pause.
So how do I prevent that?
Well, let me go to Looks, and
Show And Hide isn't what I want.
That it's going to
make the cat disappear.
So how could I change this logically?
And there's also, if I go
to Control-- is it Control?
[INTERPOSING VOICES]
DAVID MALAN: Yeah, so it
looks like it's too late.
I can't fit that there.
But again, magnetically,
it will want to go there.
So it will just grow to fit.
So now I'm explicitly
saying, wait one second.
And let's see if this happens.
Ah, so now it's giving him a
chance to breathe, so to speak,
whereby it's saying it for one second.
But rather than immediately like
close and open his mouth, so to speak,
it's letting him close it for wait
a second, then reopen it to say,
hello world.
All right, so that's all fine and good.
But it's not nearly as
cute as it could be.
I'm going to go under Sounds here.
And it just so happens we
have access to a sound block.
[MEOW]
And if I instead rip this out,
and let me find the sound palette.
And let me play the
sound meow and hit Play.
[MEOW]
Uh-oh, what happened there?
Let me try this.
Now I'm puzzled.
Let me play sound meow until done.
[MEOWING]
Not very natural but better
[MEOWING]
Let me steal this block.
[MEOW]
[PAUSE]
[MEOW]
Slightly more realistic.
Why did it not work the first time?
Remember, let me undo this,
drag this in and hit Play.
[MEOW]
I'm confused.
Why is this not working?
What could possibly explain this issue?
AUDIENCE: [INAUDIBLE]
DAVID MALAN: Yeah, maybe the sound
byte's-- it's only one second,
so it's pretty brief.
But conjecture why I'm not
hearing it 10 times nonetheless?
What's that?
AUDIENCE: [INAUDIBLE]
AUDIENCE: [INAUDIBLE]
DAVID MALAN: Yeah.
AUDIENCE: [INAUDIBLE]
DAVID MALAN: Yeah, at the
risk of like oversimplifying,
my Mac operates at 3.1
gigahertz, which means
it does 3.1 billion things per second.
And what I'm really telling
it to do is only 10 things.
But I'm not letting it wait
until it finishes the song.
So it's like this loop-- and I certainly
can't move my finger this fast--
is doing this 10 times.
And by the time it's done with all
10, the sound is still playing anyway,
so it has the effect of
really just playing it
once because it's happening that fast.
The play sound until done is designed
to block execution in that loop
until the sound is done playing.
And so even though it's
going around pretty fast,
and that's why it sounds
a little unnatural,
at least it's waiting until
the sound is done to continue
to the next iteration of the loop.
But waiting one second forces
it to linger even longer.
So it starts to sound
even more natural still.
So this is just sound.
What about movement, and
what about animation?
How might you make games or
in general interactivity?
Well, let's again grab a control block.
And let's just say forever this time,
which is a different type of loop,
if you will, or cycle.
And let's go to Motion.
Move 10 steps.
And let's see what happens here.
Now I can-- thankfully, this
is designed for children
so he can never quite
leave the stage fully.
So we can drag him back.
But the program's still running
because it's in an infinite loop.
And notice, it's colored in yellow,
which means that the program is indeed
still running.
What's going to happen if I change
the 10 to 50, would you think?
What would the visual effect be?
Yeah, faster, right?
Because this is cycling again and again.
And every time the loop goes
through, it moves 10 steps.
I don't know what a step
is, but it's probably
a pixel or a dot on the screen.
So let me change the 10 to 50.
And if now in every iteration he's
moving 50 steps, woo, it's pretty fast.
Let's do 100.
And now it's really fast.
But let's add some logic now, whereby,
let's say, sensing-- actually,
let me grab control.
So let me add an if, which is some
conditional logic, and then sensing,
because I know this is here.
If touching edge, let me change
to a different direction.
How about-- OK, that was
an accident but cute.
Let's stop that.
Let's have him change 180 degrees.
So let me-- how do I' reset the cat?
He's in a funky place now.
Well we'll just let him go down instead.
So now he's bouncing off the screen.
But this is as expected.
I didn't quite intend for it
to be diagonal, but so be it.
And now we can add another
little feature here.
Let me go to Sound, Play Sound Meow.
[MEOWING]
And now we can be a little
more ridiculous here.
This is now where we're venturing
into non-academic territory.
Let me click the microphone.
I'm going to allow my
microphone to work.
Delete that.
Ouch!
All right, so that's a
waveform of my voice.
I'm going to delete the part where
it was just silent for a moment.
Now let's go over here.
Recording One-- I didn't
give it a clever name.
Ouch!
Ouch!
Ouch!
Ouch!
Ouch!
Ouch!
Ouch!
So you laugh, but this is
what programming is fun for.
It gets very annoying very quickly.
So let's ramp things up a little bit.
I have some pre-fabbed examples
here to demonstrate a few points.
For instance, this one here, still
a cat, still involving sound.
But this one works as follows.
[ROARING]
[MEOW]
See Inside will show me the program.
So this one, [MEOW] behaves like this.
We're kind of spoiled.
But does someone want to
propose how this program works?
Read code for first time perhaps.
[MEOWING]
Yeah?
AUDIENCE: [INAUDIBLE]
DAVID MALAN: Yeah, so if you
pet this cat with the cursor--
[ROAR]
[MEOW]
So it's a nice way of combining now a
forever loop, so a looping construct,
but not just an if, but an if-else.
So there's two forks in
this road not just one.
Let's try another example
here, where let's do
this one to show the precursor of this.
This one, by contrast, does
nothing at first until you do what?
Till--
[MEOWING]
This is kind of the opposite,
where you do want to pet the at.
Let's take things up a notch
with, say, counting sheep, which
gives us a new capability altogether.
Now, even though we haven't seen
these blocks before, what does
this program apparently do?
AUDIENCE: [INAUDIBLE]
DAVID MALAN: Yes this is
kind of a play on words.
So instead of you counting sheep,
the sheep does the counting.
But it introduces a new
type of puzzle piece.
This orange thing is what
we'd call a variable.
So like in algebra you have x and
y and z, and they store values,
like numbers, in this case,
too, I'm declaring a variable.
But it's more interestingly
named than x, y, z.
And indeed in programming it's common
to name your variables in a more
descriptive way, like counter,
setting it equal to zero
and then increasing it by one, so
that all this sheep does to infinity
is counts really, really high.
Though there's actually-- you
can see a bug pretty fast.
Let me remove the wait.
So now he's counting faster.
Let me increase the counter even faster.
Let's see if I can really break this.
Let's see how high the sheep can count.
This is a really big number.
Come on, break.
The sheep is not cooperating.
My number's bigger than that, I think.
I can't quite tell what's going on here.
I'm trying to simulate a
fundamental limitation of computing,
and I'm failing.
Computers can count really high
is the take away of this example.
At some point, per our
discussion yesterday
of how many bits are
typically used to store data,
it turns out that computers-- and I'm
not quite sure what's happening here.
I think Scratch is
simplifying this for us
and only showing as part of the number.
Computers typically only
use 32 bits, maybe 64 bits,
to represent numbers, which is to
say that they can only count so high.
And what I was hoping would happen
here is that the sheep would actually
start misbehaving and start counting
negative numbers or some other funky
behavior.
It seems not to be doing that.
So it's a little resilient to this.
But at the end of the day,
this is a fundamental limit
of most computer programs.
If you only have 32 bits or 64
bits, which is of course finite,
you only have a finite number
of numbers you can represent.
That might be a really big
number, but it's still finite.
And so there have been some
very real-world examples
of this being a problem, whereby
counters overflow, so to speak.
You get to 4 billion, and then
suddenly the counter goes back to zero.
And frankly, even if you're
not quite the technophile,
you might recall that 16 years ago
we humans made exactly this mistake
on an even larger scale with a much
simpler problem, which was what?
AUDIENCE: [INAUDIBLE]
DAVID MALAN: Yeah, y2k.
Thankfully, thanks to languages
like COBOL and FORTRAN,
enough the world was fixed before the
apocalypse happened in the year 2000.
But what was the essence of
the problem back then, which
was a programming problem?
AUDIENCE: [INAUDIBLE]
DAVID MALAN: Exactly, and
why would that have been?
AUDIENCE: [INAUDIBLE]
DAVID MALAN: That's true, but why?
That is true, but that was a side
effect of a design decision in software.
Grace?
AUDIENCE: [INAUDIBLE]
DAVID MALAN: Yeah, exactly.
These two digits for
the year because most
computer software was
invented in the '60s or later.
And surely no one thought,
especially in the government,
that we'd still be running the
same software 30-plus years later.
But of course, as 2000
approached, we were still
running some especially old systems.
We were getting closer
and closer to the year
not rolling from 1999 to
2000, but from 1999 to 1000
because you are only looking
at those last two digits.
So a lot of software had
to be written in languages
beyond even these because people
had to go back and fix this.
Now, it was plenty efficient, and you
saved memory by only using two digits.
But nowadays this would certainly
be an asinine decision in software
because you all too easily start
to bump up against these barriers.
We're already running into
an issue whereby historically
clocks in computers are stored as the
number of seconds from January 1, 1970,
just because-- an arbitrary sort of
moment in time, the epoch, so to speak,
in computing.
This is not great because
you can only count so high
with numbers that are of finite bits.
And so even clocks are at risk of
rolling over for similar reasons
as well.
It's sort of y2k in a different way.
Was there a hand a moment ago?
Avi?
AUDIENCE: [INAUDIBLE]
DAVID MALAN: Either they don't,
and it's just not supported,
or you have to use
libraries that essentially
use multiple numbers to
represent one number.
So maybe the first variable would
represent the first digits in a number,
and the second number would represent
the other digits in the number.
And you have to somehow
do the appropriate math
to combine those values somehow.
But--
AUDIENCE: [INAUDIBLE]
DAVID MALAN: They would still
use special software typically.
So most modern computers
nowadays are 64 bits, which
means you can count up much higher.
Specifically, you can count up to two
to the 64, which is a number that big.
If you need bigger numbers
still, which program certainly
support, for instance, here
is this calculator I'm using.
It clearly can count
even higher than that.
That's because they're
using multi-byte precision
arithmetic, which means you use
multiple bytes not just four or eight.
You use even more than that.
But it's not built into the CPU.
It has to be done in software.
So let's take a look at
another couple of examples
of what you can do with this.
How about this guy, which is interesting
because it uses yet another feature
of a typical programming language.
[BARKING]
Here's what he does.
[BARKING]
And that's enough to get annoying.
If I hit the space bar, the program
is still running, but he is muted.
Why?
Well, notice a couple of
features of this program.
One, this program actually
has two scripts, so to speak.
It is multi-threaded, if you will.
A program is multithreaded if it can do
multiple things at a time in parallel.
The fact that these two scripts
are physically separated
captures that idea.
And there's an interrelationship
between the two of them.
In particular, what does the script
on the right do in layman's terms?
What does the script on
the right seem to do?
Anyone?
AUDIENCE: [INAUDIBLE]
DAVID MALAN: Sets the baseline?
OK, but what does that mean?
Be more specific.
The one on the right though.
AUDIENCE: [INAUDIBLE]
DAVID MALAN: Your right, yeah.
AUDIENCE: [INAUDIBLE]
DAVID MALAN: Under what circumstances?
AUDIENCE: [INAUDIBLE]
DAVID MALAN: At the
start, and in particular,
there's a fork in the
road there, so to speak.
It's a one-way fork, so
there's a decision point.
It only says, hi, hi,
hi, if what is the case?
AUDIENCE: [INAUDIBLE]
DAVID MALAN: If muted is zero.
So I'm taking some liberties here using
zero to represent false or no or off.
And one I'm arbitrarily going to
equate with true or on or such.
And so when I say, if muted equals
zero, that means if muted is false.
So what if it's not muted,
is the corresponding logic,
then play the sound and think hi,
hi, hi, and then wait a few seconds
and then do it again
and again and again.
On the left-hand side,
how would you describe
the functionality of that script?
AUDIENCE: [INAUDIBLE]
DAVID MALAN: Exactly.
If I press the space bar, for
which it's listening constantly
in that forever loop, change the
value of muted from zero to one,
else change it from one to zero.
So it's a way of flipping
the state of that variable.
So just by convention, there's
nothing for enforcing this.
I could use the numbers two and
three or nine and 10 or whatever.
I'm using zero and one by convention.
It seems to be changing or toggling,
if you will, the zero to a one or a one
to a zero based on whether
the space bar is pressed,
which means if I hit it again--
[BARKING]
-the sea lion keeps talking.
Now he's off.
Now he's on
[BARKING]
And you can liken this to
most any piece of hardware.
Like on your Android phone or
iPhone, f you hit mute or pause,
really there's probably just some
kind of loop waiting and waiting.
Hey, is he hitting pause?
Is he hitting pause?
Is he hitting pause?
If so, pause the music.
Or by contrast, and we can see
this with one final example,
software is often not sitting in a
loop like this, which is generally
not best practice
because in many languages
it will actually slow the computer down
if you're just constantly doing this.
Instead it can be event based, whereby
you tell the screening in advance,
hey when the user hits the
space bar, let me know.
And you leave it to the operating
system or some other piece of software
to let you know that, at
which point you do something.
And in particular, we can see
it with this example here.
Here are two puppets
that work as follows.
This guy-- so just to be
clear, we now have two sprites.
So the blue guy is selected in
the bottom left-hand corner here.
The blue guy's purpose
in life is to say Polo
when he receives something
called an event, per my mention
of event-based programming.
The orange guy apparently does
what when I hit the space bar?
AUDIENCE: [INAUDIBLE]
DAVID MALAN: He says Marco.
But he also broadcasts an event.
So the blue guy has registered
himself as a listener for this event.
The orange guy is responsible
for broadcasting event.
And it's not quite a verbal broadcast.
It's sort of a software thing.
You're just visually coincidentally
seeing him also say Marco,
but that's not what the
blue guy is listening for.
The blue guy's listening for
this thing called an event.
And the result here is that
nothing happens at first,
but the program is running.
But how do I make this program
do something interesting?
Hit the space bar.
The orange guy hears the space bar.
He says, Marco.
The blue guy receives that event,
and he says Polo in succession.
And so this is one way of having
two sprites, in this case,
or really two threads,
more generally speaking,
intercommunicate by way of what's
called event-based programming.
And it's a different paradigm
from just sitting there in a loop
forever, listening for
something to happen.
Now, we can be much more
sophisticated than this.
We can have multiple threads
interacting in this way.
This is an example of two
sprites, both with forever blocks.
But the cat clearly has an
advantage here because it turns out,
Scratch has a block that says point
in the direction of another sprite.
And so eventually, he
will ever so closely--
[ROAR]
--catch up to the bird eventually.
And you can see how that's
implemented in the source code there.
But then you can go even further.
And in fact, one of our
students implemented this one.
Lest you be underwhelmed by these
examples, one of our students
reimplemented this game, which you
might remember from yesteryear.
And if I full screen this and click Go,
It was Blake Walsh [INAUDIBLE]
one of our [INAUDIBLE].
So beyond getting
distracted by the '80s here,
let's consider how this
program's probably working.
I'm hitting my arrow keys right.
That's the only form of control I have.
So how is Blake noticing that I'm
hitting left key or the right key
or the down key or the up key?
What logic does it normally have?
Listener-- well, listeners
potentially, yes, or a loop.
So one of those two models, right?
There's either a forever loop saying,
hey, is the user hitting the left key?
If so, do something, move.
Else don't do anything.
And what's going to happen here?
We've not seen, this but Scratch as
a block that says is if touching.
And actually we did see this.
We just saw that block
and used it a moment ago
when the cat caught up to the bird.
It was touching the bird.
That's what triggered the sound to play.
And so what's kind of nice is once
you have a bit of understanding
of programming, you
can look at something,
even as relatively
complicated as this, and infer
how it's probably implemented.
For instance, these cars-- those
three cars on the very bottom
track-- how is that working?
Well, there's probably a forever loop.
And every time the loop happens,
there's like move 10 or move 50,
or whatever it is.
And they're all moving to the left.
And then there's probably
an if condition that says,
once you're off the screen,
secretly go back to the other side.
So those three cars,
I'm guessing-- and we
could check the code-- are
probably the same three cars.
They're just sort of magically being
reused by repositioning them there.
And that's happening with all the cars.
And why are they operating
at different speeds?
Why are they not all the same?
Yeah, maybe there's different blocks,
different loops for each of those cars.
And that's why they're
moving at different speeds.
And then to be honest, as
sort of complex as the game
might seem at first glance, there's
not much more to explain there, right?
We talked about sprites touching others.
That's how you detect a car
or if you hit the lily pad.
If you're unfamiliar with what
the heck this thing even is,
the point of this game, if I can
demonstrate this reliably-- and this
might be a bug.
I don't think this is going to be stuck
on the-- I never caught this on play.
I never just sat here talking about it.
There we go.
Now I'm on this log here.
I think it's very underwhelming.
I don't think anything actually happens.
Well, maybe if get all seven
of the lily pads covered there.
Anyhow, there's really
not much to this game.
It looks complex.
So how in the world do you go
about building something like this?
Well, I'm guessing when
Blake set out to do this,
he certainly didn't try to build
the whole thing all at once.
For instance, if you were going to build
this game knowing only what you know
right now, where do you even begin?
What would be your first
step if you were making
a to-do list for building a Frogger?
AUDIENCE: [INAUDIBLE]
DAVID MALAN: Set up
the boundary, so maybe
do the aesthetics first, like
make some kind of graphic
in Photoshop just to give you the road.
Because the road isn't changing.
The screen is physically
moving right now the breeze.
But the road isn't moving.
The purple stuff, the black stuff,
the green stuff are all fixed.
So those are just images.
What comes next?
AUDIENCE: [INAUDIBLE]
DAVID MALAN: Yeah.
OK, so the basic story, and what's
one of the first pieces of the story
you could bite off?
Like what might version one
of your game do and only do?
Maybe just the cars, right?
And frankly, I wouldn't
try all the cars.
I'm going to pick one of
these yellow and red cars.
I'm going to figure out how
to just initially put it
over there on the right.
And then let me just make it move.
And it wouldn't take
you very long, right?
I moved that cat from
the middle of the screen
to the right of the screen pretty
fast with just a couple of blocks,
a couple of puzzle pieces.
And then I might have to think about,
all right, when he's off the screen,
now I need to put him back.
But you could imagine after five
minutes, 20 minutes, an hour,
like figuring out how
to move this one car.
Then you could probably duplicate
or somehow clone that block
and make sure he spaced a little
farther away from the other cars
and do it twice, then do it three times.
And then move on to the purple cars
here and do the same thing again.
Then move on to the white and
green, and then the trucks.
It's all really the same kind of thing.
Now, in a language
like Scratch, you might
end up duplicating a
whole bunch of code,
using the same things again and again.
In more modern programming languages
there's a way to reuse code.
So you only implement one
piece of code that moves a car,
and you somehow
parameterize it or configure
it to be configurable to use yellow
car, purple car, blue car, big truck,
and maybe the speed too.
So maybe the black box
that is your movement code
accepts as input the color of the
car and maybe the speed of the car
and maybe the direction, too.
But you can reuse that code,
and that would be good practice.
And then after that,
what about the frog?
Well, we could implement
it on a separate day.
So that was my Saturday homework.
On Sunday I might implement the frog.
And using events or for loops,
I just have to somehow respond
to up, down, left, or right.
And maybe he can go absolutely anywhere.
There is no notion of water initially
because I just want the thing to work.
Then I go and implement the black water
here, which I didn't fall into it,
but I'm pretty sure I'm not
allowed to walk on to that.
Let's see.
So this is probably another feature.
It's not even black.
It's purple on my screen.
It's black on the projector here.
So it actually looks
like water and so forth.
And so this would be generally known
as hierarchical decomposition or
functional decomposition, like how
can you go about taking a big problem
and breaking it up into smaller,
much more palatable tasks,
maybe tasks that we could distribute?
So Nicolas does one thing, and
Avi does another and so forth.
So that collectively we bring
together the collective solution
to this problem.
And so that's pretty representative.
The very first program I wrote
in Scratch in grad school years
ago was this, which has been modernized
by one of our TFs now to be more green.
I implemented what's called Oscar
Time, whereby trash falls from the sky,
and you're supposed to drag it into the
trash, at which point, Oscar appears.
But as of 2015, we are green now.
So there's now been added a
recycling bin and compost bin.
And this was meant to help subliminally
teach the undergrads-- oh, that's
just not possible.
That is-- subliminally teach
people what is compostable.
Anyhow, I can say from
personal experience,
part of the process of
coding is also debugging.
Oh, that's [INAUDIBLE].
There's nothing-- I hate the song now.
Like hours and hours of
playing with this game,
trying to get it right-- never again.
Anyhow, but something like that,
what are the building blocks?
Well, I don't quite remember because
it was so many years ago now.
But I think I started
with just the stage.
Like I got the aesthetics right and
the lamppost and the trash can, just
because I wanted to have a
mental model for the game.
Then I think I just had
one piece of trash fall,
and it just fell from the
same place every time.
Then I added the feature for dragging
and dropping, so that I could lift it
and then it would fall again.
And that wasn't all that interesting.
And then I added the feature to
detect if it's touching the trash
can, at which point I hide the trash.
Then I didn't want the trash
always falling from the same spot,
so I added a bit of randomness.
And indeed Scratch and computer
programs will generally
let you have randomness--
pseudo randomness technically--
that allows you to move
the position either here,
here, here, or here, based on a
range of values that you give.
And so there too, I sort of took
the equivalent of baby steps
until the net effect, hopefully, at
least, I thought, was very impressive.
But it was the result of
very small bite-sized tasks.
And this is a general principle of
software design-- modularizing things
such that you make very small,
progressive steps, so that one,
you feel emotionally like
you're making some progress.
Two, if you made mistakes,
bug, so to speak,
they're within very narrowly defined
spaces-- very few lines of code.
And three, so that you can
work with others, each of you
contributing little pieces of code.
And this would be
generally best practice.
So why don't we go ahead and do this.
Let me pause from speaking
and propose a challenge
or so, as follows-- maybe a left
half/right half kind of challenge.
Would anyone on this
side of the room like
to propose a very simple
program using a cat and maybe
nothing more that we would like
this half of the room to implement?
What would you have the
other half of the room
implement using just one
cat as an ingredient?
What you want them to do?
So while they're thinking
of something, what
would you all to challenge the
other half of the room in doing?
AUDIENCE: [INAUDIBLE]
DAVID MALAN: Duplicates?
AUDIENCE: [INAUDIBLE]
DAVID MALAN: Is this possible?
I like it.
Is it with the clone?
Let me just-- OK, I
think this is possible.
And I will give you a hint,
right half of the room.
I think you'll need to use this puzzle
piece, which we've not talked about,
but does what it says--
Create Clone Of Yourself.
And so just to be clear,
we want something--
AUDIENCE: [INAUDIBLE]
DAVID MALAN: So I'll elaborate.
Like the cat should be moving around.
Every time he hits the edge, he should
maybe double, so one becomes two.
And maybe add some randomness
so that both copies
don't go in the same direction
where we won't see them.
There's got to be some
randomness to the angle.
You should've spoken first.
So what would you all
now like to challenge
the other half of the room to do?
AUDIENCE: [INAUDIBLE]
DAVID MALAN: So how
would this work exactly?
AUDIENCE: [INAUDIBLE]
DAVID MALAN: We can go with that.
So how about every time
he bounces off the wall,
he shrinks in size, starting
large and going small.
And feel free to call me
over, but the lesson here
is one, to just give you a
sense of the logical flow,
see how many different answers we get.
And it'll be a nice transition,
I think, ultimately, into lunch.
Avi?
AUDIENCE: [INAUDIBLE]
DAVID MALAN: You're
welcome to collaborate
with your partner next to you.
But let's get as many working
implementations as possible.
But you're welcome to lean on
someone else for some help.
And the goal here will be--
I would encourage you first
flip through all of the various
puzzle pieces that are accessible,
just wrap your mind around what
the ingredients are and then
think about how you might implement.
And if you would like to
remember some of the examples
we just did, especially involving
motion, if you go to today's slides,
after the Scratch URL is this one here.
This Studios URL will lead
you to all of the examples
that we just flipped through, if
you want to see those as well.
Despite my constant refreshing,
we have just these five.
But that's OK.
Feel free to still add if you'd like.
So let's take a look at
this one here and see.
OK, so Scratch seems
to start quite small.
He seems to be just a fleck
on the stage over there.
I'm going to go ahead
and blindly do this.
Is this as expected?
AUDIENCE: [INAUDIBLE]
DAVID MALAN: Oh, wow.
That's an unexpected feature.
And now he's getting smaller, but
he's so large, it's not very quickly.
This is the one called
left side smaller.
When in doubt, reload.
So let's see how this was working.
So we have just one script here,
and when space key pressed,
change size by 10.
I made the mistake of holding
it down in perpetuity.
So forever repeat 10
times move 50 steps.
OK so if it's OK, let's critique or
react to some of these blocks of code.
Repeat 10 times move 50 steps.
I do think there's an
opportunity for improvement here.
What could we do to express this
equivalently with less code,
so to speak?
AUDIENCE: [INAUDIBLE]
DAVID MALAN: Yeah, I would
just replace this potentially
with one move 500 steps block
just because it cleans it up.
And this would be a general principle.
If you can express as
clearly but more specifically
some operation with
less code, you should.
If on edge, bounce.
So that's what's getting the
cat bouncing back and forth.
It looks like this middle if condition,
if touching edge, then nothing,
that's probably just left
over from a previous idea.
So that could be removed altogether.
And if touching edge, then play
the drum number 12 for 0.25 beats
and then change size by negative five.
So that negative five is what keeps
making the cat smaller and smaller,
unless you're holding
down the space bar.
So let's play it once more.
That's a neat effect in the end.
So that's what the drum sounds like.
And if I hold the space, it gets bigger,
then gets smaller, smaller, smaller,
and smaller, until I do this again.
Really cute variant adding
the space bar there.
So let's take a look
at another one here.
We have a nice stage.
So someone took to heart by suggestion
you always start with the stage.
Already we have a nice backdrop here.
Let's hit Play.
So let's see, when I
start as clone, move five.
Did I hit the-- oh, there we go.
Nice.
Nice.
Oh, my god.
It's kind of mesmerizing.
AUDIENCE: That's cool.
DAVID MALAN: And what effect do you
see happening besides more cats?
This is adorable.
I think we're going to have to
use this example s the fall.
Something's happening though.
Changing of direction.
AUDIENCE: [INAUDIBLE]
DAVID MALAN: Yeah, it
seems to my eyes here
like it's all kind of
getting slower, like it's
getting a little more like stuttery.
And honestly, I think we must have
already hit the limit because.
If we're doubling every time, think
how quickly after doubling 32 times,
how many cats would there be?
Start with one cat, double in 32 times.
4 billion, right?
There's only four answers
mathematically the past two days.
So 4 billion cats, I'm pretty sure I
don't see 4 billion cats because it
probably be just a bigger mass even.
So there probably is some
limit, but even that limit
is pushing the limits of
Scratch, but very well
done in terms of the spec
and a nice pretty background.
Let's look at s third here.
Go back here.
Balloon cat, hit Play on this one.
Let's see inside.
Hit Play here.
When space key-- oh, very cute.
So he kind of pops when he
gets smaller and smaller.
And then he does that.
Nice, very nice.
Let's go here.
This one's just in-- Cat dot, dot, dot.
See inside.
[MEOWING]
He seems to be getting
progressively smaller.
And there does seem to be a lower bound
on how small they let Scratch get.
Not in this one.
Cute.
All right, it's very nice.
And let's see two more-- Scratch Shrink.
[MEOWING]
There's more randomness.
It seems to be angles this time.
This is really cute.
If hit the space bar,
it gets 200% again.
But there, too, you can see the
limits of too much happening at once.
When I hold the space bar
when he'd bouncing-- I
can't quite induce it again.
And even the sound is
struggling to keep up.
Very nice.
And the last but not
least, Runaway Sprite.
Another clone.
I love it.
It's mesmerizing.
I love it.
Oh.
That's really cool.
There's something very Simpsons
like about it too somehow.
Well, congratulations to both sides.
And thank you for the challenges.
Those were terrific.
Why don't we go ahead
and we'll take a break.
And at 1:30 we'll resume, taking
a closer look at libraries,
at frameworks, and
technologies more generally.
