35C3 preroll music
Herald Angel: Do you remember some days
ago, where you sit together with your
loved ones and you had to fix their
computers? And told them how things work –
and why they are working the strange way
they are working? Imagine you have to do
this for teaching them how to program and
give them the passion and the love that
you have for programming! So please let's
give Mike Sperber a great applause for his
talk "How to Teach Programming to Our
Loved Ones".
Applause
Mike Sperber: Thanks so much for that
introduction. Let's switch slides back.
Speaking of passion. So if you're teaching
programming, that's a great ego booster,
right? You know that. If your audience is
large enough or if you've got super gifted
children – like you probably all do – then
you know, you could teach them just about
anything and they will say, they will tell
you and they will give you feedback
telling you how wonderful that was. So for
example I like functional programming, so
that's a lambda which stands for
functional programming. And you know
whenever I teach that to a sufficiently
large audience somebody typically looking
like that would come up to me and tell me:
"Oh this lambda stuff, this functional
programming stuff that's the most
wonderfullest thing I've ever heard. And
you're a great teacher." And so in the
introduction it said something about a
couple of days. So I think I've been
teaching for 30 years now; in various
contexts: to high school students, to
university students, to kids, to
humanities majors, to computer science
majors, to computer science minors, in
professional training to co-workers. But
if I take the totality of my teaching
experience, most of that overall looking
back was a failure. And I want to talk
about those failures more about the
successes that come from the passion. So
if you look at initiatives that aim at
fostering programming skills among
children for example, they always talk
about getting people excited and sort of
exciting their passion for programming.
And you hear politicians talk like that a
lot, too. We need to get young people into
technology because that is the future. I'm
not sure about that personally, but it
always seems to end up in classrooms that
look like this: That typically have a
bunch of robots in there, sold by some
company. And that are supposed to, because
robots are for some reason inherently
interesting. They're supposed to get kids
or whomever interested in programming,
excited about programming. And that's all
good and well. Also I think there's this
underlying assumption that only if we
would get people excited and interested in
programming, they would sort of acquire
the required skills by themselves and some
process of trial and error or osmosis or
something like that. And I think the most
prominent project that propagated that
notion – some of you may remember – was
this One Laptop Per Child initiative a
couple of years ago. And you don't … I
haven't seen many of those at this
conference. And the reason for that is
that the educational concepts around One
Laptop Per Child were based on this idea
of – I think – what's called
constructivism. This idea that only if you
give children enough material and access
to whatever the Internet and teaching
materials, then they will all figure it
all out themselves and they will figure
out how to build programs by themselves.
And I think one of the underlying problems
– I mean there were many problems with
OLPC. But one of the problems was
certainly that just this approach to
didactics and pedagogy doesn't work
particularly well. And you find variations
of that pretty much every year. There's an
educational initiative built on this
notion of inspiring – you know – passion
for programming. You know, last year you
would hear about a project called Bob
which essentially is about programming a
little robot-like device, that has
blinking lights and things like that. And
it's certainly very interesting and you
program it by – I think you can see that
here – you program it by essentially
downloading already … someone already
programmed some C++ code for you, and you
take some line in the middle and change it
to change the blinking through frequency
or something like that. And again all that
is good and well; and I don't want to
denigrate that, but it's all good and well
for inspiring passion. But all of these
projects have in common is that they are
not really about teaching the methodology
of programming. And so this is, you know,
this is what this talk is about and it's
probably going to be the most boring talk
you've ever heard. If you want to inspire
passion for programming and for computers,
there's lots of projects right outside
this door – specifically today on the
Junghackertag – that will tell you how to
do that. The problem is that if you want
to transition from these projects to
actually serious substantial programming
projects that your learners want to
undertake by themselves … and if you look
closely enough, you will find that a lot
of people get frustrated by that
experience of writing more complex
programs. And even if they do not get
frustrated, their code often ends up
looking like that on the right hand side.
And so of course this entire conference is
in the spirit of tinkering and building
things by trial and error; and you see a
lot of things that look like this. But,
you know, in the upcoming IOT apocalypse
maybe we want to have a little bit
slightly more methodical approach. So the
problem is really that most didactic
approaches to programming do not work very
well. For the longest time I really didn't
have a good explanation as to why that was
and why maybe the stuff that I was doing
or that I learned how to do over the years
worked better. And so finally I found a
great book that confirms some of my
biases, that I read just the day before
yesterday – as I was preparing this talk.
And it has a couple of … It's written by a
cognitive scientist – Daniel Willingham –
and he lists a couple of principles that
are active when students learn, right? And
I think one of the things that's really
important is that we all have this
idealistic notion that everybody loves to
learn, right? But in fact learning is
quite a difficult activity and it's quite
straining. And – so even though people are
curious about things and they love to look
at things and they like to have successful
learning experiences – if that learning
experience means they have to think hard,
then at least some people shun those same
experiences. Another problem is … so and
that's of course a problem when you
transition from a primitive programming
environment, like Scratch or Bob or
something, to more complicated things that
you can easily get frustrated, and then
shun away from the learning experiences
that are required to take the next step.
Another one that I found interesting is –
so these are just all the cognitive
principles in that book – so it's kind of
very textual and boring, but I liked it so
much. So it says: "Factual knowledge
precedes skill." But if you think, so what
it means is really that you need to have …
that if you want to learn a particular
skill, you need to associate that with
factual knowledge. But if you think about
the factual knowledge that is associated
with programming, then a lot of the
principles underlying our everyday
programming skills are usually unnamed.
And they're not really put in specific
words, and so they're not in the form of
factual knowledge. And which is why a lot
of people have trouble with the skill
part. I love this bit which says: "Memory
is the residue of thought." Which is that
we don't always remember the things that
we should be remembering, but that we
remember things that we spend a lot of
thought on. And that means in particular
for educational initiatives that are
centered around robots – or something
that's really … that is supposed to take
over the passion part of programming but
not really central to the activity of
programming – people tend to think about
the robots: They tend to think about the
motors and actuators and things like that;
and those are worthy skills in and of
themselves, but they don't contribute much
to the actual skill of programming. I
remember asking a proponent of such an
educational initiative a number of years
back, you know what is it? What is the
skill that students take away from your
robot class? And he said "well, after that
class where they spend all their free time
for a semester or a year, they really know
what pi is. And I don't know for me that
is not enough. So another thing is that …
maybe that doesn't go so much towards
computer science or programming experience
but also to the way that we do math
education: Is we understand new things in
the context of things we already know. In
particular we find it easier to understand
concrete things. And I think both in math
and computer science a lot of explanations
are in the form of explaining some
abstract thing rather than showing how to
do a concrete thing. And so we'll get
back. So this is going to be a major point
later on. Something that didn't really
need saying in that book: "Proficiency
requires practice." If you want to get
better at programming, you'll need to
practice it with the goal of getting
better at it. So in the classroom or in a
teaching environment you really need to
create situations that foster successful
practice, the successful solution of
problems. So that, you know, this natural
curious part in the beginning. So student,
so people generally derive a dopamine rush
from successfully solving problems. So we
really need to put … we really need to put
our students in a situation where they can
successfully solve problems – that are not
too hard and also not too easy, because if
they're too easy, the dopamine rush will
not be big enough. Here's a trap I think
that most people who teach programming
know about is that "cognition is
fundamentally different early and late in
training". And if you're here, most people
in this room are late in training. So
we've been in touch with computers for a
long time, so our cognitive processes when
we think about programming are different
than the cognitive processes of beginning
students. Sometimes that's also called the
curse of knowledge. So just because we
find some piece of material inspiring or
interesting – or some technique of
explaining something very persuasive –
that does not mean that our students find
it similarly persuasive and find it
similarly easy to follow along our
teaching. If you're teaching big
classrooms I think there's being have been
a big push towards individualistic
learning. And of course that's wonderful.
On the other hand our children tend to be
quite alike in their style of learning.
And so I'm not going be talking about that
much that very much today but there's
still great value in having a classroom
with several students that are all being
taught the same thing. Not a subject today
but I could also … that that also has been
confirmed by my experience. Generally,
some people think that you know some
people are good at math and some people
are bad at math. You know girls are always
bad at math for some reason and it turns
out that this is … Well first of all it's
not true. And even if you feel you're bad
at something then usually what we call
intelligence can be changed through
sustained hard work. I think you know 10
or 20 years ago a lot of people believed
in IQ that an innate ability to learn
things. But it turns out that that most of
the effects of IQ on your ability do
things well are quite indirect and through
the environment rather than through some
structure in your brain that you were born
with. And so that's something that you
really learn when you do 30 years of
teaching is really that your teaching can
improve over time. But in order to improve
you really must get feedback and you must
practice it and get feedback the same way
that the skill itself must be practiced.
And that sometimes gets you feedback that
is surprising sometimes and also it's
often quite quite painful because
sometimes you get the feedback that you're
teaching just did not work. So really, I
want to aim a programming education at a
diverse audience and not just I mean if
you look at the Robot class if you're
student population that ends up being in
that robot class is really as diverse as
you like it as you'd like it to be. I
think often that is not the case. So the
stuff that I'm going to talk about and
then I'm going to talk about has been
applied not always by me but to children,
to high school students, to university
students, professional developers and
works quite well. And what it is based on
is a set of systematic methods and I'll
try to show you in great and painstaking
detail what that means. And so here are
some references that you can look at. In
particular we built on the work of the PLT
group in the U .S. led by Matthias
Felleisen, who have a great book out now.
I'll give you a reference to that later.
There is a there's a significant project
for teaching high school students in the
U.S. and there's also a project that I'm
involved with what's called which is
called "Dein Programm", which tries to be
sort of the little German sister of that
stuff. So one aspect that's important to
this method of teaching is that all the
tools that we use are geared towards
learners in particular that means that
there is a specific programming
environment that was made specifically for
learners rather than your Emacs or VI or
whatever your favorite thing is that you
want to, that you want to inflict on your
learners. I don't think you should. I'm an
Emacs person myself. So also what it means
is that we have … that we use specific
programming languages that are derived
from real programming languages but that
have been modified to be especially
suitable for learners. And also then we
have something called the design recipes
which are a set of methods for systematic
program construction that try to provide
this factual basis for the methodology of
programming. And so there's programming
environment … All of this stuff by the way
can be downloaded for free. And so there's
a great system called racket developed by
the PLT group but there's a tiny corner in
there that I'm going to refer to today
which is great for many things but it was
originally designed and still is great for
teaching so. So let me try to switch to
that. I hope that works out. This moment
always scares me. So here is the system
called Doctor racket and you can see it
has not very many buttons it does not look
like Eclipse or Visual Studio or something
like that does not look like a
professional programming environment. And
the way this works is I'm going to try to
show you how it works is in the upper part
of that window there's just the program
that's a text editor with a couple of
special features - not very many. And down
here is the REPL, which you can use to
interact with the program that you've
written. I'm not gonna use that very much.
But what you can do in the REPL - in the
beginning at least - is you can just type
something and it will give you … it will
then immediately tell you the result of
the evaluation of what you typed in. And
now you have to remember … This is gonna
be alien and strange to you. But the way
this works is these languages are based on
Lisp. So they use round parentheses a lot
and specifically when … always when you
want to put something together they have
around parentheses and they have the
operator in front and - especially if
you've been programming for a long time -
you think "Oh no, this is … Never gonna
get used to that!" but I can promise you,
your children will have a very easy time
dealing with this. So you could go and say
you know you could just type a number and
it will give you the result. You would
type a string, you know, "Mike". It will
give you the result. It … you could go and
you could you know, you could combine
numbers, right, by adding them together.
You could let's do away with that. Looks
like this. So that's what it what it looks
like a compound expression has always
parens around it and the operator in
front. So you don't really say you know
this number plus that number you say the
sum of those two numbers. OK. And so gives
me the result of that. What's kind of fun
if you're a C programmer or Java
programmer this is kind of fun, but
children love this for some reason I know.
So what you can also do is the same way
that you're used to having numbers and
strings and whatever and booleans be
values. Pictures are also values so that
sometimes helps when you're trying to drum
up that little piece of motivation that
you need. So you could do like a rectangle
that is solid blue and that's a value. And
whatever whenever there is a value you can
write a program that binds that value to a
name by writing "define". So you could do
something really exciting like this. You
would define "pi" for something. We could
run that program and then we could put top
pi here but we could also do you know "r"
that rectangle and whatever 50 solid red
and we can run that program. And here's
that rectangle. What's maybe more
interesting is that we can maybe do
another rectangle that's solid blue and
you can also see here's the same principle
at work right. Parentheses around the
define so "define" says it's a definition
and the rectangle is just a call to a
function that comes with Dr. Racket and
it's also in front. And so I could do
that. Now I have "r" I have "f2" and I
could also do things, things like you know
there's for example a function that takes
two pictures and puts them beside each
other so there's a little jumping ahead a
little bit there's a little algebra of
pictures in here that you can use to
program video games for example later in
the class if that's something that you
want to do. So this is not entirely
without motivational examples. So there's
that. Yeah. Let's see how far we can go
from there. OK. So but getting away from
those motivational examples. In German we
are very big on traffic rules. Right.
Straßenverkehrsordnung. So there are many
rules, right, and we'll try to model that.
This is going to make this the most boring
talk you've ever heard. So we're gonna
categorise German traffic violations. So
in particular there's two kinds of traffic
violations. There's red light violations
where it's important where they happen and
it's also important what the duration is.
How long after the light has turned red
passes before you actually cross the
intersection or the red light. And then
there's a speeding violation where you
also have a place and you just have how
many kilometres per hour did you go over
the limit. And we want to write functions
and I'll tell you how to do that for
yielding the place of a violation and
classifying a violation as serious or not.
And for that purpose we're going to do …
use something called the design recipe or
rather as there's we're going to use
several design design recipes and first of
all there's an overall design recipes,
which says how you write a function. And
please don't fall asleep. There's one,
two, three, four, five, six, eight, eight
steps to this. And we always ask our
students to always go through those eight
steps and you think: this is off. I mean I
hope you do right. You feel this is this
already looks like the most boringest, you
know, exposition to programming ever. This
is like the German bureaucracy approach to
teaching how to program. On the other
hand, so, but, you know, it works. That is
the point. Specifically each of those
steps is something that is small enough so
that students can usually successfully do
it. And if you can reward it with credit
or candy or whatever then you know
students will be motivated to get to the
next step. You know if you've ever taught
unsuccessfully and probably most of you
have always taught successfully but what
always happened to me is then when my
teaching would be unsuccessful my students
would be staring at a blank screen. Right.
And that would give them this problem and
I felt this problem was really solvable
and they would give up before typing the
first key. Right. They wouldn't know where
to begin because there's usually most
approaches to teaching how to program are
example based. They give you some example.
You know, here's that program solves that
problem. How here's a different problem,
now solve that. And you already saw how
that's done. And that process usually or
often does not work. And so this fixed
sequence of steps gets students over that
hump and I'm gonna try to explain that
really in painstaking detail because the
books don't really do justice to a how
bureaucratic and painstaking it is. So you
all have the benefit of that. So there's
always these eight steps and then there's
more instructions that come with each of
those steps. Right. But these instructions
are eminently learnable and that's the
important aspect here. So in particular.
So I'm gonna, sort of, jump in right
ahead. Oops, oops. Ah. You see something
that I don't see. There we go. So if you
look at this problem statement. So let me
go back one more. So it says the first
thing that you do is well you draw a short
description of a function we already have
two short descriptions of the functions
you know find the place of a traffic
violation and find out if it's serious or
not. And then it says please conduct a
data analysis and data analysis means that
you look at the entities in your problem
and and analyze them. And here it says
while this is all about traffic
violations. And it says something of the
sort. That there's for example a red light
violation. And it says that red light
violation has place and duration and that
duration is in seconds. So one thing that
you can do is you can look at the wording
of how that data is described and if you
discover wording that says you know this
thing consists of these pieces. Right. Or
this thing has several different
properties. This is a phenomenon that we
call compound data and that has a special
design recipe that PowerPoint somehow
threw away. See OK it comes up again. So
it says well you recognize compound data
by a description of your data that uses
words like "consists of" or "has". And
then you write a data definition of that
form and I will show you how that works.
Then, something really trivial comes you
count the ingredients and you write a
what's called a record definition that's
actual code and then you ensure that the
counts match and these are instructions in
the textbook. Right. And students learn to
memorize those instructions and you all
going asleep. You know you're all falling
asleep. Sorry about that. So let's see
where is the right window. Here's the
right window. So that's what we were
doing. Right. I'm going to leave that here
for your entertainment. It says well a red
light violation… So excited, I need to
talk. And we said it has this formulation
that says "has". We're just going to write
it down in a slightly more systematic way.
So, it has a place and it has a duration
in seconds. Right. And that's just a piece
of natural language and those semicolons,
they make this a comment. OK. So we didn't
do much except writing each component of
our compound data in a separate line. And
then it said - I can't really display it
at the same time - then it said, write a
record definition and a record definition
has this form. It is, it really it looks a
little tedious. But it's actually quite
valuable. So it says we're talking about
red light violations so we give our thing
a name. So that's called "red-light-
violation" then we will need to create
"red-light-violation" objects. So we will
need a constructor so I'm going to write
down the name of that constructor.
Eventually we will need to distinguish red
light violations from other things. So I'm
going to write something it's a predicate
that we'll use a little later and then we
have two parts. And I can't emphasize
enough how important it is that you sort
of remember: two. Right? It has two parts,
because it says that there's a place and a
duration in seconds and we write the names
of things that will extract those pieces.
So we go here it says "red-light-
violation-place" and "red-light-violation-
duration". Or we could, let's call it
seconds, so we always know what that is.
And now what that does is when I run it is
well it doesn't do anything. But what we
can do is. We can now create objects that
represent red light violations. And so
what we could do is… Well let me first
show you how it's done. We do "make-red-
light-violation". You know there's one in
Borg. Somebody who, you know, had a red
light violation for four seconds in Borg.
Right. And then it will display a record
value that shows what the parts are that
we had. And so I can copy this up here and
call it and make an example out of that.
And so like this. So now we have "rv1"
here. So this is what's called a
constructor and this constructor when we
call it creates this object and this
object really creates data that is
associated with information. So that's an
important aspect to explain. And so
usually we ask students and I can't I'm
not writing this down to explain it to you
I'm writing it down to show to you what to
expect from students. And so you go "Oh",
make them do it. So this is a red light
violation in Borg, 4 seconds. So it seems
really trivial to you but it's important
to really … to link the program to the
problem domain that we're in, right. So we
have a minor red light violation here.
Am I spelling this right? Anyway, so here
we go. And one way to talk about this new
function that we created "make-red-light-
violation" is writing down something that
we call a signature. It looks like, sort
of like a type signature but isn't quite.
That's something that we did specifically
for teaching. So you do "make-red-light-
violation" and remember in math you would
sometimes write f Doppelpunkt, f colon to
denote a type. And here we just put the
colon in front. So it says "make-red-
light-violation". Well it takes a string,
that says what the places is, it takes
some rational number, that says how long
it went, how long the red light violation
was over the limit, and it creates a red
light violation object. So that's not
gonna do much, unless, well let me let me
show you something. If I wrote something
else here I wrote a number here.
Something… Where'd it go? So it's, so it
says it gives an error message here. And
it's I think it's due to this full screen
mode for some reason. Let me see if we can
do this again. No, not quite. OK, now we
know what it is so. So. Yeah it was. So,
when you. Unfortunately it is in German so
I hope some of you read German I'll try to
translate it says well this program still
has to be tested but it says there was a…
It says here "Signaturverletzung", which
means signature violation. And it says I
got five in this line here. And really, so
this is the five. Oops, right here in this
line. And it violated the signature here.
So it gives you… So the system. That's one
aspect of what makes the system
specifically designed for learners is that
it gives you very specific feedback as you
run the program. OK. So let's do away with
this. Let's get this down here. So now one
of the challenges or one of the problems
in the problem statement was to write a
function that determines whether a red
light violation is serious or not. And so
when we do that, it said, well, you put a
short description in front. And so here's
a short description. And there's lots of
religious wars about how many comments you
should put in a program but to our
learners we say put one line not more not
less in front of every function. And
that's usually about the right level. So
is a red light violation serious? So the
next thing is. Well if you remember that
slide it says, well, if you're writing a
function, if you're implementing a piece
of functionality, that always ends up
being a function in functional
programming, you write a signature for
that function that talks about what goes
in and out of that function. So in this
case. Well we have to make up a name for
that. So it practically writes itself here
and so we just put so in this language you
can put a question mark in the middle of a
name and you can also put hyphens in the
middle of a name. And what we want is we
want a red light violation to go in and we
want a boolean to come out that says
whether that violation was serious or not.
So those are already steps in that design
recipe that you saw. And so if you're in a
classroom situation or whatever you can
give credit for each immediate step and
you should, because those are already
those are all small successes in your
programming endeavor. So the next thing
that you should do is, you should write
examples or tests. Those are almost the
same thing here. And so, fortunately we
already have examples of red light
violations. So we just have to write down
how we expect our function to behave with
respect to those examples. So there's
something called "check-expect" and I hope
you recognize that principle that we're,
that things are always named in the front.
So we could say "red-light-violation-
serious?". With children you might want to
pick shorter names if they can't type that
fast yet, but with grown ups this works.
So the first one is four seconds over, so
that's pretty serious. So we expect that
to be true and that "#t" means true. And
so. And you. And the other one is half a
second over and that's not so serious
under German law. That's fine. OK. So the
next step. So now we've written. So let me
let me label those things right. This is
the short description. This is the
signature. These are the tests. And now
you write something called the skeleton
and the skeleton is just you start writing
the function but you already have some
information about that function you know
the name of that function and you know how
many things come in and out. So you write
- oops typo here - so and, well, this is a
functional language so somebody always has
to write lambda somewhere. So when we make
a function in these languages we always
write lambda. So we want to make a
function that accepts one thing and that
is a red light violation a red light and
we'll just call it "rlv" and we'll just
put three dots here. So the three dots I
don't mean to say we're gonna fill in the
rest later. It means in class when I do
this I actually type three dots and in
class especially at the beginning we
actually ask our students to type the
three dots because this is the skeleton.
This already gives you credit and it's,
you know since this is so easy to do, it
really means that there's, you're not
staring at a white piece of paper and
maybe you feel encouraged to do that next
step. Now the next step says you have to
fill in what's called a template. And
those are elements of the function that
you're writing that derive from the data
that goes in and sometimes from the data
that goes out. In this case the data that
goes in is one of those red light
violation objects and that red light
violation object if you may remember is a
compound object it has two pieces. And
whenever you write a function that accepts
compound data with two pieces you probably
need to look at those pieces. So, what you
do is, you write you have to write
something that will tell you what those
pieces are and remember. So I haven't
actually told you how that works. But
remember here was the record definition,
up here, and it told us and we have a
signature there that tells us how to
construct a red light violation object.
And so what we also need is we need a way
to get the components out of a red light
violation object. So we need what's called
selectors or assessors. And those are the
things in parentheses here and here and
you can also describe them with
signatures. And strangely enough so and
here a red light violation thing goes in
and a string comes out. And in this case,
a red light violation goes in and a - what
do we say - a rational comes out. So those
are of course… Those signature
declarations are redundant. You don't have
to put them in there. Redundant with a
constructor declaration and you're
going asleep, you're going asleep
anymore... Even
more probably than you were. But I had an
epiphany in class where I would only write
the constructor signature and the students
would ask me to also write the excessive
signatures. And so they made me even more
bureaucratic than I was already by then I
already was by nature. So now here what we
do is we want to get access to the
different parts. So we write "red-light-
violation-place" of "rlv". So that's one
piece. "-violation-seconds" of "rlv".
That's the second part. And those are
building blocks. So really if you're
really strict about it you might have
people type three dots in here also. So
these just say, these are building blocks
for your function. And so you think about
how those parts contribute to the answer
to your questions. The question was is the
red light cycle violation serious or not.
Then you can think about. Well is the
place relevant whether it was serious or
not. And in Germany I think it's not. But
it is relevant how many seconds you went
over. So, you then have– then you go
through this conscious act of: you've
written it down but now you delete it
again because you've done a little bit of
thinking. And you go and, well, then you
look up– I look this up on the Internet.
If it's over one second then – or if it's
one second or over – then it's serious,
and then you delete all the ellipses and
make sure all the parentheses close and
then you run the program. And here's still
the signature violation that we need to
fix. So it says here again there's a
little German sentence because these
languages were designed for Germans and it
says: both tests were successful, because
we wrote two test cases here. OK. So this
bureaucratic approach just goes on and on.
So I'm just going to go through the second
iteration more quickly. So it said you
know what did it say. It said, it said
this. We also have a speeding violation.
So let's go through the motions of that: a
speeding violation has– again, it also has
a place and it has, you know, how many
kilometers per hour over. And we write a
record definition
something like this, and we could do,
you know, two speeding
vio- so now we have a data definition that
says: oh we've got two components, we've
got a record definition that needs to
match that. You all think this is trivial
but with compound data our students often
have trouble. So it serves you well to
remind them that there's two pieces, and
those two pieces need to be selectors in
the record definition. So we have speeding
violation one, speeding violation on Main
Street. You know what, 20 kilometers over,
and we have another one, you know low
street or whatever, that is 25 kilometers
over. So that is two examples right. And
we have one on low street, 25 kilometers
per hour over limit. So once again the
speeding violation constructor has a
little signature that says well a natural
number goes in, speeding violation object
comes out. And so we go through those same
notions. I need two things in order to
demonstrate one more thing. So then again
the question was: When is a speeding
violation serious? And of course a
speeding violation goes in and a boolean
comes out. And so we will write two tests.
So speeding violation in Germany is
serious when it's 21 kilometres an hour
over the limit, or over that. Right. And
it gets progressively more serious after
that. So. So the first one is not too
serious. We'll not get you any points in
Flensburg. But the second one is. And once
again we go right, speeding violation
serious, we write the skeleton. So then we
write the skeleton, then we fill in the
gaps and says we really should be writing
calls to the accessors. So we have the
place of the speeding violation and we
have the kilometers over of the speeding
violations. And then we think a little bit
and then we realize: oh the place does not
matter. So I'm skipping. Of course this
all goes on usually over a longer period
of time that you're teaching. I'm going
I'm going pretty fast here. So we do away
with that and we go well this really if
this is over 21 then that's bad. Okay. So
let's see if that works. It says km per
hour over– So then it says all four tests
are passed. So that's good. So you know
there is primitive data, there's compound
data. You may have noticed that on the
slide it said: a traffic violation is
either a red light violation or a speeding
violation. So that's not compound data.
When you see this formulation in your
language that says: it's this or that or
that or that, or maybe it is one of the
following. Then you're not looking at
compound data, you're looking at a
phenomenon called "mixed data". So you've
seen this, you've seen this, you've seen
this mixed data. So you recognize it by
either the words "or" or "one of" and you
write a data definition that really has
that form, you count the alternatives just
like you do with compound data. You write
a signature definition. I'll show you how
to do that. And you ensure that the counts
match. And so the way that you do that is
this. We said data definition, so we said:
a traffic violation is one of the
following. It's either a red light
violation or it is a speeding violation.
And just as with the compound data this
little data definition has some code that
goes with it. So we'll just call this
thing a traffic violation and we just use
define to say what that is and define
traffic violation, is it just a signature
that says it's mixed, it's mixed data from
red light violation and speeding
violation. So here you go. So now we can
use that in signatures. You remember the
problem statement didn't say: find out
whether a red light violation was serious
or a speeding violation was serious, it
said: find out whether a traffic violation
is serious. So you know it is a traffic
violation, but so far we only have
functions, one works on red light
violations, the other one works on
speeding violations, but they don't work
on that mixed. So we'll try to do that now
and instead of writing red light violation
we'll just write traffic violation to
boolean. So we could now write tests that
match those that are there but I'll spare
you that. But in class we absolutely would
need to do that. And now what we do is,
when we have a traffic violation– Remember
how I said if you have compound data, you
put calls to the accessors in the body,
and then you go on from there. But now
we're looking at mixed data in the input.
So mixed data has a different template and
that template says: well if you're looking
at mixed data, maybe this or that or that,
you should probably find out what that is
before you do anything else. And for doing
that we use a conditional we use something
like this– So what we need to do is we
need to distinguish red light violations
from speeding violations, so we need some
function that will tell us which one it
is. And this is the last bit up here in
the record definition. You remember that
we said red violation here, red light
violation here. This is the name of the
constructor, so it is the constructor.
These are the accessors. And this is
what's called the predicate, and the
predicate tells us whether a thing is a
red light violation or not. So in this
case the predicate says: red light
violation question mark, or "p" is what
the programmers in these languages say.
And it takes anything and it tells us
whether it is a red light violation object
or not. I'm just gonna copy that down so
that we remember. We're almost done. So of
course the same thing goes for speeding
violation. So we need a conditional that
has as many branches as we have
alternatives in the data definition. And
again you think this is super trivial and
childish, but it works very well for
making successful programmers. So we need
two branches, and the way that works is
this. So you write this out with ellipses,
and then you need to come up with tests
for the two branches in this case the
tests are: is something a red light
violation or is it a speeding violation.
So we have this, question mark tv, and we
have this which says, speeding violation
tv. And now here we just need to put in
the answers, and the great thing is we
already have the answers we already have
two functions that tell us whether a red
light violation is serious and so we can
just call that here and we can do this
here so and then we're done. So I think
that's all we can do in this hour that we
have today. So I hope you see two things.
First of all this is super boring and
super bureaucratic. But maybe you can see
that every single step that we have here
has is a principle that has a specific
name and that you can explain in very
specific concrete terms that are not
abstract. And that means it can really
explain every step that's needed to solve
this problem. And I can't tell you what a
game changer to that is for teaching. If
you really ask yourself if, you know, when
you when you present an example to your
students whether you can really explain
every single step and explain to the
students here's what you should have
thought, you know, here's how you should
have picked what to do next. That usually
ends up badly. So so one of the principles
behind this style of teaching is really to
be absolutely sure every single step that
you expect your students to make when they
solve a problem has a name and has been
explicitly taught in your class. So every
technique has a name. You noticed me
saying compound data and mixed data and
design recipe and template and skeleton.
And so this is the factual knowledge that
we use that precedes the skill that we
want to then induce. If you're teaching a
class that has rewards you reward every
single step. You really insist on form. I
also can't stress this enough so on our
home page you find a paper that says form
over function. We don't accept any program
that is correct. We just accept the ones
that match the form that you've seen. We
also measure success. You know you really
need to look at how well your teaching
style is doing and you improve it
continuously. So those are the important
principles. You might think that this
stifles creativity. And I really don't
think that's true. And I think that is
based on a misguided notion of creativity.
So if you talk it successfully creative
artists they really also rely on a set of
named techniques that they use to tackle a
creative problem. And so somebody always
says Mozart you know Mozart never had to
learn or practice before he got to be a
great composer but Mozart started it so
early in childhood that he had his 10000
hours of practice in there to be before
most people even start. So this works for.
So this has been proven to work this
approach for children. I think I would
start about 11 years, beginning
programmers. It's worked for programmers
that had learned some other via some other
approach you know bad habits and
professional developers. There's two
websites that you can go on to get more
information. One is our American sister
project called programmed by design that
has lots of material, links and
publications. The DrRacket software that I
showed you. And there's also a book in
English how to design programs. And it
doesn't say that here but that book is
available for free online but there's also
a print version. And similarly if you're
looking for German language material
there's "dein programm DOT de" which also
has links and publication, links to the
same software. And the draft version of
that book is there too. And hopefully
we'll have a print version of that also
next year. And that's all I have for you
today. Thank you very much.
Applause
Herald angel: Thank you Mike for that
talk. If you have any questions, we do
have the microphones lined up here in this
row and in that row and does the signal,
yes the signal Angel has a question.
Signal Angel: Yes, so one IRC user asks
what are the benefits of using this
DrRacket tool instead of for example
Python which was also developed for
teaching?
Mike: So Python is definitely not
developed for teaching, not in any
meaningful way. So in practice, in
practice I think the fundamental diff-, so
but there's a lot of educational
initiatives around Python. The thing is
really that if you try to name and really
formalize the techniques the systematic
techniques that I showed you and apply
that to Python programming you will find
that very hard. I personally found it
impossible. Most Python programs out there
in practice are just not developed
systematically and I don't know how to do
that. And so that is where that is much
better. This corresponds to these
programming languages were designed in
lockstep with the didactic principles that
underlie them and as far as I can tell,
I'm sorry about that, Python was not
developed with any didactic principles in
mind whatsoever. Sorry.
Herald Angel: OK then. Microphone 2 please
go now.
Questioner: I teach roughly 14 years olds
in the middle school and also programming
and I use the App Inventor right now. The
App Inventor, MIT Media Lab App Inventor,
I […] with scratch and I'm not sure you,
you said okay you need to buy Lego
Mindstorms robots and stuff like that or
scratch or MIT App Inventor. That's not
the case.
Mike: No. Yeah.
Questioner: And what I find difficult for
the students I have there they are not the
best from the best parents, then they
would like to show something in the end.
And it's your program looks a lot like
Mike: Superball!
Questioner: it is really very boring and
laughter how do you bring it over that
point? I find it so valuable that in the
end they can show it on their smartphone.
Mike: Yeah, depending on your target
audience of course you choose different
examples and this example just had a lot
of things. You might have seen me show the
pictures, show the picture algebra at the
beginning. So that's something that tends
to work great for children and older
children alike and that scales all the way
to writing video games and there's an
entire book that shows children or young
people on how to do that. So that's one of
the great aspects of this. I think that's
a fundamental difference to things like
scratch and so on this approach to
programming scales all the way to
programm-, to professional programming and
it scales to substantial video games. So
the students that we so we always used to
do that the halfway point in the first
semester at the university and they were
able to write a complete like 80s style
you know frogger or snakes or something
like that that looked pretty fancy. And
that's something I think that your
children could take home.
Herald Angel: OK. Then microphone 1.
Questioner: Hi, thanks for your talk. I'd
like to know so your approach adds a lot
of let's say overhead that is also
necessary to be taught. How do you go
about the methodology in the actual
classroom though. Yeah. Do you al-, do you
also have some recommendations on how to
tackle the actual design of the of the
class, what methods do you use, do you use
a flipped classroom or what do you do?
Mike: A good point. So so mostly the
classes that I have taught they are taught
just like what I did just now. So I try to
demonstrate that to really make that clear
because it hasn't really been documented.
I could refer you to friends of mine who
have taught a flipped version of that
which also seems to work quite well. But
the important thing really I can't stress
this enough that as a teacher and I
skipped a couple of corners just now to
fit in the time slot was that you go
through all of those motions that you
always go through all of that motion and
that's a great tool not just for giving
every single step a name but also for
pacing the classroom and that and the rest
kind of tends to fall in place has been my
experience, right. No matter whether
you're looking at you know beginning
students or professional programmers. I'm
not sure I answered your questions but
maybe you can take the rest offline.
Herald Angel: Thank you. Microphone 3
please.
Questioner: Yes. I think this is very
great but it is teaching functional
programming and many people will very soon
need imperative programming. How do you do
the switch or can you do it?
Mike: So I I would dispute that but.
Laughter
Questioner: Well if you want to get paid
for it.
Mike: Thank you, go, go.
Laughter
Mike: So I run a company that does all
their software projects doing functional
programming. Ultimately you will need to
talk about effects. The thing what this
does really is I mean if you're writing
software professionally you know no matter
what the language is, large parts of that
should be functional. So this is a great
way to teach good programming discipline
and a lot of programs out there don't show
good programming discipline. So I think
this would be great to improve upon that.
So what this does is it pushes the
boundary. To be honest I have no idea how
to teach systematic development using
imperative languages. I don't know how to
do that. I don't know how to do it and I
don't know how to teach doing it. On the
other hand what I can do that do here is I
can push the imperative parts of the
programming to the fringe and make them
less important for the success of my
project and for the structure of my
project. So yeah. So you should. This is
the good thing because we know functional
programming works well and we know it is a
good foundation for an educational
discipline. And yeah I can't, I mean there
are there are various courses that build
up upon this, but ask me offline about
that that tackle that imperative
programming.
Herald Angel: OK then microphone 4 please.
Questioner: Yeah I'd like to thank you for
your talk too and I'm curious what's your
experience how many repetitions do you
need to teach your students until they
settle with the principles. Do you teach
like three examples or is it up to 10
examples?
Mike: I'm not sure I have a solid rule for
that. So my experience has been, so I think
every principle here usually has like two
in class examples at the university level
and then has maybe three or four examples
where they do exercises and that's usually
enough but your experience might vary. I
don't I don't think I have a good rule for
that. Generally you might not have gotten
for this but so the point of comparison
and where I have the most experience is at
the university level. Overall the
progression of material in here is really
really fast compared to your traditional
Java course. So you can cover a lot of
material using that. I'm not sure how many
how many university students or university
courses have successful video games in the
middle of the first semester and there are
nice programs that are well structured so
so surprisingly maybe even though this is
so boring and tedious it allows you to
write programs successfully quite fast and
also goes to lots of teaching to go quite
fast.
Herald Angel: OK. Microphone 2 please.
Questioner: Hello, thank you for your
talk. When I learned programming as a kid
quite young and I think that I could
transport tools and the mindset also to
mathematics and full blown problems.
Mike: Yes.
Questioner: So I just wanted to ask if in
your experience can children also use this
systematic way of solving, I mean do they
really make this transition? Can, are they
getting better at solving problems?
Mike: Yeah absolutely they do. So if you
look at one of the three projects I listed
was the Bootstrap Project which is which
is aimed at high school students or middle
school students and there the approach is
specifically tied to the algebra part of
mathematics and so this is where you'll
find exactly what you're looking for. And
that's been that project's been usually
successful and they have lots of material
on how it should be taught. So that's
great stuff.
Herald Angel: Okay, we have two more
minutes and two questions. So Microphone 1
please.
Questioner: Hi. How do you measure success
in your teaching?
Mike: So mostly at the university level
we look at the final exams and we have a
few papers out that are referenced from
the web page there. That's I mean usually
what we do is we have pretty close
supervision, even at the university level.
So we look over students' shoulders all
the time to make sure that we're teaching
them at the appropriate level and at the
appropriate pace. But over the years we've
seen measurable improvements by looking at
the final exams and very specific ones. So
we don't just look at the overall grade we
look at individual problems and see all
the progress has been and what we expect
and there's papers out on that.
Herald Angel: And micr
ophone 4 please.
Questioner: Is there some kind of auto
completion in your editor or do you not
advise us to use this feature for
beginners?
Mike: Laughter. No there's not auto
completion as far as I know. I'm not sure
I would advise against it. I know that my
American colleagues they've I mean as
you've noticed write the templates as it's
sort of always recurring program elements
and you could imagine there being a button
that inserts that program fragment and our
American friends they experiment with that
and they came out not using that in
practice anymore. But I can't tell you
details on how that is. But if you're
interested you could send me email and I
could find out. So for some reason so I
can't tell you why and I'm not I'm not
ideologically opposed to that but we're
not doing that.
Herald Angel: OK then. Mike thank you for
that very enlightening talk and become a
big applause for that talk.
Mike: Thank you very much.
Applause
postroll music
Subttitles created by c3subtitles.de
in the year 2019. Join and help us!