35C3 - How to teach programming to your loved ones

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!