*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!