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]
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!
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?
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.
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.