ASHLEY WILLIAMS To learn ES6 from scratch, you must first invent the universe | CascadiaFest 2015


>>All right. Hey, everybody. All right. So
the first thing I’m going to say is my slides are online. So if you like following along,
you can do that there. There’s not too much interaction going on, but you might be interested
in checking out the reading list that gets involved in this and everything citing at
the bottom of the slides. And like I said my name is AG dubs, and I’m coming to you
from New York City. I’m an engineer at the Mozilla foundation. And what I work on there
is open source software that’s focused on universal open Web littery, and I
like making open source projects that let
me think about thinking. And in particular especially the type of thinking that happens
when people write code. So something I also like to do is I have a
teaching background. And before I do anything, I like to say that I make mistakes. And everybody
makes mistakes and I’m probably going to make some during this talk so hopeful you guys
can respond with some empathy about that. And does anyone even know what my talk is
about? Probably not. How about art? This is some really cool Internet art that I found.
Super into it. But I’m actually not cool enough to talk about art. I don’t really know a lot
about it, and that makes me sad. So I’m going to talk about JavaScript. In fact, I’m going
to talk about ES6. But before I do that, I’m going to take us on a little detour, and I
know that’s a bummer because I’m what stands between you and dinner and drinking and pool.
Well, that’s try to make it through this party before we have the actual party. So, again,
we’re going to talk about abstraction. This wouldn’t be a good computer science talk if
I didn’t kick us off with some. So let’s do that. And so Dykstra says the effective exploitation
of his abstraction — and sorry about that best of your memory of prow noun there. Of
their powers of abstraction must be regarded as one of the most vital activities of a competent
programmer. So we’re saying, like, when we’re doing programming,
like I am doing programming, what I’m really doing is I’m abstracting. So what do we actually
mean when we’re talking about abstracting? So Benjamin in this book defines the abstraction
principle as each functionality in a program. Where similar functions are carried out by
distinct pieces of code. It is generally beneficial to combine them into one by abstracting out
the various parts. So this probably shouldn’t be blowing anyone’s mind. Hopeful not at least
because I know the enjoy of programming to me is being able to refactor things in just
this way. Like, it just feels good. And so hopefully you guys also enjoy that.
But in this talk, I want us to think of less practically about abstraction and more academically,
theoretically. And so I went to Wikipedia, obviously that’s where you go. And here in
Wikipedia, it says abstraction tries to factor out details from a common pattern so that
programmers can work close to the level of human thought.
I don’t know think about that for a second. And then leaving out details, which matter
in practice but are immaterial to the problem being solved.
And that’s something I want us to flag. Immaterial to the problem being solved. We know that
as programmers, our solutions are almost 50 percent defining the problem. And so as we
walk through what I’m about to say, I want us to be thinking about what problem are we
trying to solve with JavaScript? All right. So another detour. Slight detour. I was lucky
enough to be the lead instructor at the New York City Web development fellowship, which
is a boot camp-type program that was run by the school called the flatiron school and
it was students who made very little money or unemployed put through this six-month program.
They had very little background in programming, and then we got them jobs as junior developers.
I agreed that some of these boot camp programs have some serious problems. We’ll talk about
them now. But I learned a lot, and I know that the students learned a lot. And these
are the students right here. And one of the things that I learned. Was
that for beginners, iteration was hard. And it’s a really critical, critical task. It’s
a good concept. So about three months before the fellowship began, I was at a user group
in New York City with the dean of the school. And the dean had put these two blocks of code
up on the board. And he said. Look at that JavaScript. That is gross. Look at all that
punctuation. But look at this Ruby each. It’s so expressive, even your mom can understand
it. Sidebar, moms are smart and cool. Do not be
rude. Yeah. So I’m not going to be aligning myself with
the ideas of the dean. He said, yeah, JavaScript, boo. So even though I’m not going to necessarily
agreeing with him, he does have a really important point. And these two excellent hand gesturey
type computer scientists, who wrote a book I’ll talk about a little bit later. They have
this great quote which probably says what the dean was trying to say a lot better. Which
is programs must be written for people to read. And only incidentally for machines to
execute. And I say this, and you can probably kind of agree about it. But how many times
when we’re writing code do we think more about the way it’s going to execute on the machine,
the performance and not what’s going to happen when someone tries to read it six months later?
All right we write program. We use programs. We read programs. We maintain programs. Computers
do some stuff over here. The computers don’t really care. And so this is something that’s
really important. And once we can understand this, it’s actually
presents us with a huge problem because behind in this quote is a really interesting question.
And that is what does it mean to write a program for someone to read? What level do we start
at? Because, you know, following instructions is really hard for some people. This is an
actual picture of my door. Yeah. That did not work out. All right.
So, again, this is a problem. And so with that, I want to share another story.
So, again, I had been to this user group, the jury was out for me at least, like, Ruby,
JavaScript, what’s better? And I was sitting at my computer while my code teacher was teaching
iteration to my class for the first time, and I’m hearing at the side of the ear, headphones
off, it’s not going well. Like, people are really not understanding how to use this each
method and even though it’s supposed to be so expressive written in the language, students
were getting it. And with that I had an idea. And I decided to do something bold, and if
you know me, I walked over to the classroom and I was, like, I’m going to hijack this
class. I have an idea. I want you to forget all the Ruby you just learned. In fact, pretend
that Ruby doesn’t exist. And I’m going to teach you iteration in a language that you
don’t know. And everyone’s, like, that sounds like a bad idea.
And I’m, like, just give me a chance here. And everyone is already frustrated and pissed
off so they’re, like, all right. Fine. We’ll do it. So I proceeded to teach iteration using
JavaScript. And this is why. The JavaScript for loop, even though it contains an intense
amount of punctuation, actually does something excellent. And what it does is exposes the
under lining concepts of iteration in its sin taxation. Iteration needs three things.
It needs state, it needs condition, and it needs increment.
Suddenly it’s there in text. It’s not behind in magic, you can manipulate it, and then
suddenly everything worked out really, really well. If we look at that Ruby each, sure it’s
there. But it’s abstracted by the key word each. And the students didn’t know what that
did, and the for loop definitely showed them. So that was really, really awesome, and we
went back, we taught Ruby, we went on, we didn’t teach JavaScript for another three
months. But using JavaScript as a teaching tool helped people understand programming
concepts in a way that is expensable to all different types of languages.
And so my secret physicist boyfriend Richard Fineman said something similar about this.
The real problem in speech is not precise language. The problem is clear language. It
is really quite impossible to say anything with absolutely precision unless that thing
is so abstracted from the real world as not to represent any real thing.
So we have a question here. We’re at a weird intersection with programming. We’re both
doing things that are really precise. But then we’re also humans coming from places
in the real world where what we need is clear. All right. And so you may have recognized
my cows and space painting as a bulls obstruction painting, and he comes in on this and says
there’s no abstract art. You must always start with something. Afterward you can remove all
traces of reality. So we have a question here. When we’re thinking
about designing programming languages, particularly as tools for teaching beginners whereby do
we begin? So you may recognize this slide. I don’t know if — yeah. It’s a good one.
So I don’t know if I’ve been to a conference that hasn’t had this slide, so I’m, like,
just doing my part here. But, yeah, so this is the only curse word in the deck, unless
I fuck pick up I mean. Anyway. So here’s how to draw an owl. Step one. Draw
some circles. Step two. Draw the rest of the owl. And this is exactly where we are when
we think about designing programming languages. There are things in our languages now that
do this to our programmers. And I’m not an artist, so I look at this, and this, like,
frustrates the hell out of me; right? So imagine being a programmer and having a language to
this to you. That sucks. And that’s something that we can work on. These are both problematic.
We are in a position here where we both need to do something that connect us to the real
world. But also is precise, and it makes us able to express things in our programming
language. We know that by using abstraction we can be more efficient. And we know by we
can also be obtainable. And how do we mitigate that?
So our journey begins in the place where we can connect those very precise idealistic
things we do in programming with the real-world things, which is we’re help you and we’re
going to start a journey. You may say a personal voyage here with Carl.
So human beings are amazing pattern recognizers, we love patterns, we’re able to look at something
like this all right? And see that. All right? We’re actually really terrible at things,
like, books. Books have no visual rhythm. We can’t see anything, and we have terrible
short-term memory. We much prefer things like this, things that have and visual cue. Again,
we see things like this, you see this. You do see it; right? I mean somebody saw it and
got a lot of people to agree with them. So when we make — when we see these patterns,
we make these patterns, and we give them names, that’s what an abstraction is. And the thing
we need to do is we need to be careful about the abstractions we make. Because bad abstractions
are big problems. Here’s an example. And, you know, maybe this
isn’t wrong because I guess I do have a lot of opportunities to speak today. According
to my horoscope. But there’s always horoscopes like this. And this is an abstraction that
has become the ideology of a community, and we realize that the abstractions are our culture.
And when we make the abstractions, we have people sink time and money into things like
this, which are not true because they don’t expose the real mechanisms that under lie
the concepts all right? So let’s talk about JavaScript. JavaScript
has been a delightful programming language because it has lots of abstractions. But that’s
all about to change. So September 28th, 1980 was when JavaScript
was invented. That’s not true at all. I gotcha. Just kidding. It’s actually when this amazing
show cosmos came out. And Cosmos was to make it accessible, and it wasn’t about pop science
all right? It wasn’t about that I fucking love science, Facebook me, that’s such garbage.
This is about real and making it real for people. And this is something that I think
is really important, and in it. Carl Higgins says this. If you wish to make an apple pie
from scratch. You may first invent the universe. And I say if you want to learn ES6 from scratch,
you have to learn the universe. So let’s talk about ES6. From the spec we
read syntax is relaxed to enable it to serve as a easy to use scripting language. And relaxation
is super cool. You’ve been relaxing — we’re all at this great resort. Who has been relaxing?
Yeah, relaxation is not always the right message. Not always what we want to hear; right? So
is the job of JavaScript to be easy to use? Is that the problem we’re solving? Is there,
like, not another easy to use language? That doesn’t seem very ambitious; right?
I mean we really need to ask ourselves, what is JavaScript trying to solve really? Like,
when we look back at JavaScript and some weird historical artifact, what are we going to
look at it as? What will JavaScript’s legacy be? And that’s a pretty heavy question, and
I’m not in the authority to answer it. But if somebody asked me, and I do think you should
also ask yourselves. I’m going to say it probably has something to do with this. And this is
a tweet from Lori Voss of NPM and he says fundamentally it’s hard to think of a compelling
reason a brand-new Web DEV would learn two languages when they can just learn JavaScript.
If I could pick any language in the world to use on both server and client, it might
not be JavaScript. But we don’t get to pick. So this brings me to our danger Robinson where
I’m going to warn you are about aliens, and those aliens are ES6 classes. So I’m going
to start off by saying that sugar makes me sick, it actually makes me sick, I have type
one diabetes, but also syntactic sugar makes me nervous. It makes me really nervous because
when I see syntactic sugar, it probably means there’s some under lying concepts. And I’ve
already kind of made my point that I’m not into that all right?
Is let’s go to the script. Even though the script includes syntax for class definitions,
script objects are not fundamentally class based. Okay.
So we have a way to talk about something that’s not real. So you might not need class syntax.
All right. So this is my favorite person that I quote in this talk. If you remember anything
from this talk, please remember this quote or go about Doritos. Either one.
He says remember that all models are wrong. The practical question is how wrong do they
have to be to not be useful? All right. So how wrong are we? All right.
In a class-based object oriented language in general, state is carried by instances,
message is carried by classes, and inheritance is only by structure and behavior. And script,
the state and methods are carried by objects. While structure, behavior, and state are all
herniated. Okay. So that’s actually kind of like a mouth
full and if you’re not into reading all of this stuff, maybe don’t really know what this
means, so I’ve got a bet for you. You might know him from Twitter for saying awesome things
like this. He wrote a great blog post, and I’m not going to read this to you. But the
idea is when we teach classes, classes are generally if understood as blueprints. The
class is a blueprint, and then we make an object from that class. And that object could
be understood as a house. In JavaScript we have something different.
JavaScript classes are model homes. So you can leave them empty but someone can move
in.
So what we have here is JavaScript classes are — they’re objects. They’re not really
classes. And when you hear me say this, you might hear me say go home, GC39, you’re drunk.
But this is not a hate talk. And I want to say right now, this happened to me today,
but never criticize without offering something. And I lo have the work that people who work
on open source projects do. So this is the most I’m going to say shout out to all the
work you do, it’s thankless and so good on them. I love them all. But I do have a perspective
to offer that I think a lot don’t have. And also a really cool way to criticize me right
now is what even is a class. And if I had 30 more minutes, I would talk your ear off
about this. If you want to hear administer, talk my ear off at the pool. I would love
it. But what I do want to say in JavaScript we
might be trying to do maybe too much. And not really be any of the things that it is.
This is a real place. You can go to at Madison Square Guarden in New York City. So, yeah,
the perspective I want to offer is that of a educator. So Leslie Lamport has a really
great presentation thinking for programmers, and in it he speaks about writing to programming.
And he says writing is nature’s way of letting you know how sloppy your thinking is.
So what I want to offer is this. Teaching is natures way of letting you know how sloppy
your understanding is. And it’s through teaching that we understand
how difficult the concepts that we are building in our languages are. And so how do we deal
with this? So they wrote this poem and it’s the first book that said we need to teach
programming concepts, not syntax. And immediately what we should hear now is a conflict. In
JavaScript we have a syntax that doesn’t expose the under lying concepts. So how — I mean
it will be a nightmare to teach classes. It’s going to hurt. JavaScript will be the introduction
to programming concepts for an entire generation of developers, regardless whether or not we
want it to be. So when you think about things being immaterial
to the problem being solved, we need to realize that JavaScript is a teaching language. It
can be a lot of other things, but it is a teaching language. So Peter van Roy is a excellent
computer scientist, he’s really awesome. He wrote a follow-up to that book SICP, and said
we need to teach programming as a unified discipline. We need to understand that programming
disciplines are tools. All right. And these tools address problems. And so when we solve
those problems, the connection of the problem and the solution is called a paradigm. So
programming languages can be single paradigm, multiple paradigm, but this means that there’s
not a bad programming language. There’s just a good programming language for the job. All
right? Problem solution pairs paradigms. So in this
vain what Peter Vinroy says is that we should use something called the colonel teaching
method where a good way to organize the programming source is to start with a simple language
and then extend the language gradually. When he teaches his students, they start with nothing,
literally nothing and then they build everything up based on the feeling to need to have that
abstraction. Feeling the pain all right? And then in this sense we understand that
building those abstractions is building this universe. The set of abstractions that we
have in a language are the universe. All right. So obviously when I’m saying is every beginner
should write out a can you recall language; right? This is a really, really bad idea.
Let’s not do that. Instead what we need to use it is the creative extension principle.
We don’t have to start from the beginning. We can’t start from the beginning. But what
we can do is we can understand that we need to build abstractions when we feel the pain
of them. And this is not, like, a new concept necessarily. All right. We know as software
developers that we should really only implement things when we actually need them. Never would
we just foresee the need for them. However, this has been a really strange concept in
computer science education. So it’s an important part to the universe.
So basically what I’m trying to say is as we are thinking about programming languages
and program language design, we need to keep an educators perspective, and I have this
slide in here just so that if you ever look back at it, it’s a summary. But at the times
I don’t have — which I don’t care about, I’m going to leave you — sorry you guys can
yell at me later, with something that I believe is really important because we’re all together
now, and these are the questions that we should be asking ourselves. So we should take this
opportunity and what I want to ask is what do we even mean when we talk about programming?
All right? One of my favorite philosophers wrote a book
called what is called thinking. And in it he asks — or says, the most thought provoking
thing is that we are still not thinking. And so I am dead serious. I want you to ask yourself.
Are we programming yet? If what we mean by programming is really this awesome feeling
of abstraction, how much time do we spend doing that instead of typing punctuation into
our terminal. A lot of really awesome people are doing things on this axis. There are people
who are radically rethinking these things. There are people going from not even typing
to dragging and dropping components. But all of this is happening in the academy, and I’m
pissed because I cannot afford grad school. But at the same time there’s no reason we
can’t be doing that here in the industry. So Thomas Coon is a amazing philosopher, and
he said through consequent exposure in literature, often without knowing or needing to know what
characteristics have given these models the status of community paradigms. We need to
think about what our paradigms are. I don’t want us adding the features that are much
like an Abercrombie shirt in middle school. We do not need to be the cool things. We can
think about that. All right? So we have an awesome opportunity to more
radically think about how we extend JavaScript. We’re in that period right now. It’s being
writ in, and this is a really awesome time. So legal leave you with this. It is far better
to grasp the universe as it is than to persist of illusion, however, assessing.
So let’s reconsider our intelligence, do it often, and let’s stay beginners. Thank you
very much. [clapping]

2 thoughts on “ASHLEY WILLIAMS To learn ES6 from scratch, you must first invent the universe | CascadiaFest 2015

Leave a Reply

Your email address will not be published. Required fields are marked *