34C3 preroll music
Angel: Our next speaker is Mike Sperber.
He's CEO, CTO at active group, co-
organizer of the annual BOB conference,
developer conference, and expert in
functional programming. He has about 20
years of experience in teaching
programming in high schools, universities
and other contexts. In his talk Mike will
share his experiences and gives us an idea
on how changes and culture methods and
tools in programming might contribute to
the future of software and software of the
future. Please enjoy the talk by Mike. The
stage is yours.
Speaker: Thank you very much.
Applause
And did she say 20 years?
I'm older than that.
So I appreciate you staying up this late.
Ah, so I'm all grown up now, so talking
about growing up: so I graduated at some
point and got a degree in computer
science, I got a PhD many years ago and
now I'm CEO of a software company that
carries some actual responsibility.
But as I was preparing this talk
I thought back to the
past and it happened to be the year in
1983 when I started hacking and, ah, well
I wasn't there. But it must have been the
year of 1C3 right? Ah, and so if you read
what was written about the computing
revolution that was to come in the early
1980s. A lot of what we're having
arguments about today was already there.
Computer security, data governance,
surveillance. All these things were
already on the radar of the media back
then. But a couple of things were
different, also. So here's a major German
news magazine that had an article on
computers in children's rooms. And not
everybody had a computer back then. So if
you were a kid like me who was interested
in learning about computers and didn't
have one at home. There was a place you
could go to, which was the local
department store. And, well, the picture
isn't very clear, but that's actually a
local department store that had rows and
rows of home computers set up. And
plugged in and ready to go for children to
to play with. And so back then, there
were, you don't remember this, but there
were many different kinds of home
computers there was no internet. There was
very little in the way of readily
available literature on how to program
computers. So we all had to figure it out
by try, by trial and error. And we didn't
really have a good methodology of how to
program computers. Now, fast forward, a
couple of years: I looked unbelievably
geeky in 1986. By then I had my own
computer and that must have been even the
second or third one that I had. And you
know by the time I was an exchange student
in the United States. They made me
president of the computer club. You can
see another picture of me right there. And
that was my first experience of teaching a
formal course. So that was in 1988 and
that was the end of that year. So that
means I taught my first computer science
course thirty years ago.
And I then ended
up designing the intro programming course
at the University of Tübingen and taught
that over more than 10 years. I taught
programming to humanities majors. I've
done a lot of professional training by now
and, well, if you're sort of a compulsive
educator like I am, everybody around you
suffers, right? Your co-workers, your
friends, my children certainly, my
relatives. A lot of them have had to
endure, you know, one or other kinds of
programming course from me. So back then,
as we were trying to figure out how to
hack computers, you know as there was very
little available literature, we also
looked for role models and here's an early
role models from the 80s, a man named John
Draper, better known as Captain Crunch
because he used the whistle that he found
in a cereal box to manipulate the US phone
system and then actually went to prison
for it. So but John Draper also is not as
well known for actually writing software
and he produced one of the early word
processors that was available on personal
computers called Easy Rider, that I
actually used, and there were reports on
on the prolific programming style that
Draper practiced, so I don't know if you
can read this, the joke is if Draper were
writing math routines for addition he came
up with the answer two plus two equals
five, he would put a clause in the
program, if two plus three equals five
then that answer is four and that's
generally the way he writes programs.
Who's seen programs like this, where yeah,
a lot of you right, where somebody adds
clause after clause of special cases until
you know, so the special cases encountered
in the wild are all covered. So, of
course, you know it in 1983 we all figured
out ourselves but people by 1985 the
Hacker Bible came out and already worried
about how we would educate children about
computers in the future and so there was
an article about computers in school and
I'm gonna zoom in a little bit and as I'm
sure I'm sure you've been involved in many
discussions on how to teach programming to
beginners and as always that discussion
focuses on the programming language that's
being used. Back then, you know the
popular languages were somewhat different
from today. There was BASIC, Pascal. BASIC
had that reputation of producing spaghetti
code, Forth is mentioned, LOGO is
mentioned and C is mentioned there. And a
prominent, back then a prominent,
professor of computer science in Germany
said well as long as you don't program in
BASIC you'll be fine. Right, the pure fact
of not programming BASIC is gonna keep you
from writing spaghetti code. And as we now
know that isn't really true and I'm sure
most of you have seen really crappy and
spaghetti code in production but the
bullets kind of keep hitting closer,
right? I think this must have been two
years ago when a vulnerability in popular
IoT devices essentially brought down the
internet because they were all assembled
into a botnet that brought down a popular
DNS provider and github went down, I think
that's what most of you probably remember.
There was HeartBleed that I'm sure a lot
of you remember, due to a vulnerability
a buffer overflow because in
OpenSSL, which was written in C, there was
Equifax which divulged a lot of social
security numbers because of a bug in
Struts, in the web framework that they
used and more interestingly, I think for,
for students of the past there was the
CloudBleed vulnerability which would
divulge secret passwords and account
information on webpages just as part of
the web cache. You wouldn't even have to
ask it, you know, secret questions as you
would have to ask CloudBleed and that was
oddly reminiscent of something well none
of you remembers unless you're as old as I
am which was the BTX hack which was
one of the founding stones I think of the
Chaos Computer Club, where people were
able to make the computer of a bank, that
was attached to BTX, divulge passwords.
Essentially a memory dump that will
contain passwords and then transfer a lot
of money from that bank to them and so
that felt a lot. So the present in many
ways it feels a lot like the past did and
you would think there would be some kind
of progress and I think I was as guilty of
that as anybody so in 1986 I wrote my
first book and as many books now and
then it focused on a specific programming
language, of course I picked like the
worst programming language in hindsight,
that I ever could have picked on that it's
responsible for a lot of the
vulnerabilities that we see today. So, but
again, you know it was at least, I can say
it was in 1986, so it was a long time ago.
A long time ago. So you would think things
have changed. So some of you may have been
at a talk earlier today about the Bob
system for teaching for teaching young
kids on how to program and Bob prides
itself on teaching programming in exactly
the same way as computer experts would
program, but it would use an approach used
based on gamification to teach students,
right? And so you know in 1986 we were
programming in C, so Bob now is programmed
in C++, so something has happened since
then. And you can look at a lot of pages,
web pages and systems for teaching
beginners on how to program. Here's a
prominent page supported by a lot of major
organizations called start coding de from
this year and you can see again that a lot
of the stuff that it teaches where first
of all is focused on particular
programming languages, on Scratch and
Python and Processing. So there's right,
there's three programming languages
mentioned there and if you can read the
fine print and if you can read German it
says "spielerische Herangehensweise",
which means that there is a that there's a
fun based, a playful approach to teaching
how to program and that's common to a lot
of things. So if you go to a kids space
you will find a section there called
"Jugend hackt" and you can see that it
also takes a very playful approach to
teaching and if you look at its material a
lot of it also features particular
programming languages. And there's, if you
look you, will find that there's a curious
absence of methodology on these, on all of
these pages, and I think part of the
reason is that, I think, if you teach
programming, you can easily get the
feeling that it's very easy, right? I mean
you can teach people to write very trivial
programs that will blink an LED or do
something like that and you know light,
the lights, the eyes of your students they
will just light up and they will just love
what you teach them, if it's trivial. If
it's not so trivial, so I like functional
programming, which is sometimes not so
easy, but in any given group that's large
enough you will find a few Sheldons that
will just eat up everything that you teach
them and they will come to you. And they
will say "oh I just love", whatever it is,
the lambda calculus, functional
programming, whatever and you know, if
you've been at it for thirty years you
notice that it doesn't really matter what
you teach you will always find a few
Sheldons that will tell you that they
love what you teach them. And so after a
while you though, you realize that, well
there's a few Sheldons but then there's
also a lot of students in your class who
are not Sheldons. And as you're chugging
along on your teaching train and you look
out the back you suddenly realize that
you've left a lot of students behind. They
might still like what you're doing but you
really haven't taught them any, you know,
significant abilities and so over the
years I've had a lot of opportunity to
think why that is. Why is teaching so hard
and why is it often unsuccessful? And one
of the reasons is, that I think if you
pick up any almost any book on programming
or open any webpage that tries to teach
your programming, it uses an approach that
I call teaching by example. So here's a
book by a computer science professor, came
out this year, and you know "Learn Java
the easy way" and the easy way is in the
second chapter right after the
introduction, we do an example, right? And
there's a concrete listing of a concrete
program and the text essentially is just a
commentary for that program and then the
expectation is, that from the example that
you've seen, that exposes various elements
of the programming language, like while
loops and System.out.println and whatever,
you will, I think by osmosis, or some
other magical mechanism absorb the ability
to apply the techniques to new problems
and my experience has been that that often
does not work for the great mass of
students were not Sheldons.
I thought back to the great teachers that
I've had, maybe not in computer science
but you know what methods were they using
and then when I thought about it, I
realized that they were using methods that
were completely different. So here's a
picture of my eleventh grade English
teacher, Anne Carvalho, in 1987. That was,
as I was an exchange student in the US and
at the beginning of the class she handed
out a piece of paper, well you can't
really see it, so I'm gonna zoom in, that
said you know, how to write a composition
in this class, right? And so composition
of this class, well here's the second
section, is the body, right. The body is
three paragraphs with each paragraph
developing one of the areas of the thesis,
first area scope, usually one paragraph,
transition topic sentence. If you look at
this, this is a very precise outline that
explains the function of just about every
single sentence in your composition. So
it's a very rigid harness, if you will,
for a composition and you know, coming
from Germany, Germans are generally very,
they don't accept a lot of power distance
and they don't they authority that much,
you know, I was an instant rebel to this
concept and it took me most of the year to
really accept that it was a great way to
learn how to, to learn one good and
working way of writing a composition and
then I could branch out from there and
develop other working ways of composition
so this is a methodology for doing
something that is extremely useful and
powerful when you teach.
And you might say, well we have
methodologies like that in computer
science and in programming as well, you
know we've been doing object-oriented
programming which is supposed to be very
principled. I've seen a lot of crappy
object-oriented code as well. I don't know
about you. So you know, an object oriented
programming well it has encapsulated
state, it has polymorphism and it has
inheritance. Inheritance is particularly
bad because there's so many different uses
of inheritance and typically your
programming language will only have one
mechanism and so people often get it wrong
and they do inheritance the wrong way
around and there's empirical studies but
there's many other ways in which object-
oriented software is sort of ends up
looking like this. So I don't, yeah
anyway, so you know, this is not, this is
not supposed to be an indictment of the
hacker culture that we see a lot of things
that you know around the corner, you know
around here that look like this and
they're wonderful but they're no
substitute for, you know, they are no
substitute for a method, for
methodologically sound development of
software. So yeah, well many yars ago I
thought there has to be a different way
and I got together with a man called
Matthias Felleisen who happens to be a
fellow German bureaucrat, like just like
me, but who lives in the US and who wrote
a book called "How to design programs"
which you can find online, if you're
interested. You don't even have to buy the
paper and we kind of did sort of a German
version of that working with Matthias
called "Dein Programm" which also has a
free book on it. And the overarching
principle of that approach is that we try
to be systematic about everything, so that
we try to attach systematic fixed plans or
system to every step of program
development and these things are called
design recipes. Just it was a name
invented for this. So I'm gonna, well I
guess I'm going to torture you with one
concrete example, a classic example. So
Matthias was in Texas at the time, so the
classic example is animals on the Texas
Highway. And we're gonna concern ourselves
with two kinds of animals, so there's an
armadillo on the left and there's a
rattlesnake on the right and there's of
course the highway in the middle, okay? So
we'll start out with armadillos and for
the purpose of this application you might
just describe armadillos. So what's
important about armadillos here you'll see
why, is an armadillo has the following
properties: it's alive or dead and it has
a certain weight. And so I'm going to
greatly shorten this process of systematic
development here, but what we say is, well
if you find yourself describing your data,
this is a data centered approach, if you
find yourself describing your data with
words like "it has the following
properties" or "it consists of the
following parts" then you're dealing with
something called compound data, so this is
a fixed part of the plan and it has a
name. That's very important to give names
to things, so you can talk about them. And
so once you've identified that you're
dealing with compound data, you can model
that data and you can translate that model
into code and here you see a screenshot of
a system called DrRacket which is a
programming environment, that was
developed for beginners, and you can see a
little program fragment in a programming
language also developed for beginners, in
fact that fragment was developed for
beginners, that says, well, in the
interest of brevity, we're abbreviating
armadillo to "dillo", so it says, we're
dealing with dillos, so we're calling the
datatype, if you will, we're calling that
dillo. If we're dealing with compound
data, we need one way to construct it,
so we need a constructor
and so we're gonna call
the constructor make-dillo, we'll see
later that we'll need one way of
distinguishing dillos from other things,
so we'll need what's called a predicate,
ignore that for now, and on the previous
slide or here in the data definition the
comment that is in yellow, you saw that an
armadillo has two components, it has two
parts and therefore there need to be two,
if you will, getter functions and those
are called dillo-alive P and dillo-wait.
Never mind all those parenthesis, at least
not for the purposes of this presentation,
oh and one one more detail maybe is, that
if you look here, it says language.
DrRacket is a programming environment that
has many different programming languages
and this particular one, as I mentioned is
called "die Macht der Abstraktion" which
identifies one particular set of
programming language levels for beginners.
Now, you know, once you have that record
definition you can immediately call the
constructor to go to, to make examples. So
here's two example armadillos, so you see
these two expressions make-dillo and this
hash mark T means true, so make-dillo true
and ten means, well, we have an armadillo
we're alive is true and the weight is ten
so that might mean an armadillo that's
alive and weighs ten kilos. And then
there's another armadillo that well alive
unfortunately is false, so it's probably
dead and it weighs 12 kilos and the
defines there just say, well we're
gonna call the first one d1 and we're
gonna call the first one d2 - okay? And so
one way to talk about these functions that
we've created is by writing down what we
call signatures, they're almost type
signatures, not quite, let's say what
these functions behave like. So the
constructor function that you just saw
applied is called make-dillo and you know
in these funny programming languages most
things are written in prefix notation, so
make-dillo accepts a boolean and a number,
remember that was that a live thing, is
it's still alive and the number that says
how heavy it is and it produces a dillo
object. And the dillo-alive and dillo-
weight getter functions both accept a
dillo object and the first of them says
whether the dillos are live or not, so it
produces a boolean and the second one
produces a number that is the weight of
the dillo, okay. And so why is this all
relevant? Life on the Texas Highway is
animals get run over by cars, right?
So we're gonna write a function that
simulates that process. So that thing in
green is what we call a problem, as a
short statement on, a short comment on
what the function does that we're about to
write, so we're gonna run over an
armadillo and then it says we're gonna
write a function called run-over-armadillo
and it goes from dillo to dillo, which
means, well, the dillo was not really a
dillo, it represents the state of the
dillo before it gets run over and then one
comes out of the right side, on the right
hand side that says what the state is
after I've gone run over by a car, ok? And
then you can write. So you can see all
these things are sort of required elements
of the curriculum, I'm going over them
very quickly. The two next things are
example and test cases at the same time.
So check-expect says, well, if we run over
that first armadillo it was still alive,
it weighed 10 kilos. After we've run it
over it's dead and it still weighs 10
kilos, okay? And the second test case
says, well, if we run over d2, it is
already dead, so after that it's still
going to be dead and it will weigh 12
kilos. Now, from the signature above, you
know we already know what the function is
called and how many arguments it has, it
has one argument, so we can write
something down mechanically that is what
we call a skeleton, which is that thing in
the beginning, the thing at the bottom. So
we're writing a function or something
called run-over-dillo, lambda says that
it's a function and d says well that dillo
up there it's going to be called d here.
This is a mechanical process and so we see
here how that is elaborated. We can do
more things mechanically from this because
dillo is compound data and whenever we
accept compound data as input we probably
need to look at the parts to do anything
that's meaningful. So we might as well
call the two getter functions. So there's
dillo-alive of d and dillo-weight of d and
also compound data comes out as output and
so, we probably need to call the
constructor. In our constructor dillo then
is supposed to come out the right hand
sid. So all of these things can be written
down and we ask our students to write all
this stuff down and also actually write
down those ellipses marks, the three dots
and these are building blocks and they are
completely mechanical, they have nothing
to do with the actual purpose of what
we're doing and then usually it's pretty
easy to then fill in the missing steps and
say well we are not really interested in
whether the dillo was alive or not before.
We're probably, but we are interested in
the weight in constructing that new
armadillo and does it still run over a
function that does that. So a large, so
you can see that there's a lot of steps,
it's an extremely bureaucratic process
producing that program. And some of those
steps are completely mechanical, they
might be boring but they enable everybody
to make progress. And so you might imagine
I said rattlesnakes and rattlesnakes are
very similar to dillos, I'm gonna run over
those very quickly. So rattlesnake has the
following properties: thickness and
length. And you can see there's a record
definition, there's a bunch of signatures
that come out of that. We can do a purpose
statement, says all we're going to run
over a rattlessnake now, not we can't just
do armadillos. There's a couple of test
cases and rattlesnakes can run over, you
know, they get flattened out. So their
thickness goes down to zero when they get
run over. But the important thing is now,
we might think about, well, we're just
going to run over whatever animal comes
under our wheels next, so we were
interested in an animal on the Texas
Highway and an animal is one of the
following: it's either an armadillo or a
rattlesnake. And whenever you see that
wording, it's one of the following: it
this or that or that or that. You're
dealing with something that we call mixed
data and so, again, this thing has a name.
And with mixed data, again, there's a
fixed set of steps that you go when you
program to them. So you define a signature
that says, well, animal is a signature
that's mixed from dillo and rattlesnake
and we're then going to write a function
that runs over an animal and so it doesn't
have dillo to dillo or it doesn't have
rattlesnake to rattlesnake, it has animal
to animal. It has test cases like as
before and, well, remember that there were
two different kinds of animals on the
Texas Highway and in, so we and we need to
feed them differently, right? It's a
different thing of running over an
armadillo and running over a rattlesnake
so for that, we need a conditional and we
need these predicate function that says,
well, that animal a is it an armadillo or
is it a rattlesnake and then we need to
fill in the gaps. And of course we've
written those functions already, so it
gets pretty easy. This is, I don't know if
you've seen this, and I've run over this
very quickly and I've left out a lot of
steps, this is an extremely bureaucratic
process and when you read about this at
first you think: "this is so boring, I
can't, I can't", you know this, you know
you go like this right. And interestingly
if you practice this on your students,
surprisingly pretty quickly they go like
this, because they realize that this
bureaucratic approach actually makes them
produce a working solution on their own.
Some of them can't believe it, that it's
successful, but then they start smiling.
But it took a long, long time to a develop
this approach. So Matthias has been added,
I think since the early 1990s, I've really
been involved in this process, I think
since since about 2001. So really you need
to take an approach to teaching. You need
to observe how well it does and I can't
stress this enough: when you observe it is
not enough to measure the popularity of
what you're doing, it's not enough to ask
your students "do you like this stuff",
right, "is that something that's
interesting", you know? I've seen a huge
bandwidth of things where we were
unsuccessful, but people just liked it,
just people just liked it fine and so,
this process, you know, we repeated many
times and hopefully gonna repeat it many
times in the future. But it has produced
the following insights. You need, so it's
very useful to have a very bureaucratic
approach to programming that we call
design recipes. I didn't much talk about
the fact that it's very helpful to have
programming languages that are
specifically developed for beginners or
for learners, doesn't have to be
beginners. And it also helps to have a
programming environment that was designed
for beginners and, well, you can go either
to a page called "Program by Design" or
"Dein Programm" and you'll find a lot of
information about that. But it took a lot
of work and it's usually, it's not enough
to just take your professional programming
language and stick it on your kids. It
might be, it might work for trivial
programs, but it's not going to scale
anywhere. So, yeah, well it's about
growing up, but I guess this one is about
growing down. So I think the progression
really should lead us, from you know, the
C and C++ like unsave languages and all
the hacking of the past and that we like
to use when we make exploits to save
languages and runtimes and finally, we're
seeing something like Rust and ATS coming
up, I really only know how to do this
bureaucratic and systematic approach to
programming with functional languages and
if you've watched this closely, you saw
that what we did, was type driven, right?
We looked at the way our data is organized
and then organized our programs according
to that data. Whether you use a statically
typed language or not is kind of secondary
to that, but in the future I think we'll
see more of that. You will write down a
specification of what you're trying to do
as part of your types and then your system
will generate for them and that's also a
way of proceeding very systematically. So
I think when you're teaching programming
it's, you know, being inclusive is very,
very hard, right? It's not enough to get
people excited. It really is important to
impart practical knowledge and competency.
And the only way I know don't know how to
do this, is to teach a systematic
approach. You might call it bureaucratic
if you're German, but to my surprise even
the Sheldons like this after a while
anyway and we should really refocus or we
need to focus you know after all the
exploits we'seen over the past couple of
decades on correctness and I think this is
the path to do that. Thank you very much.
Applause
Angel: Thank you Mike for this
presentation. We now have like two or
three minutes for questions. Please go to
the mics one, two, three yourself. Ah, we
have from there.
Q: Hi! Mic on? Yes. So coming from a lot
of the software development world and
practical experience probably, delivering
with other customers, have you got any
insights into how people would often do
teaching by code review, a direction for
people to go in reading, to learn more
about code, learn more about the structure
of code, in the way that software
development often is typically taught? Do
you have thoughts on that specifically in
this?
A: So I think it's valuable but in my
experience it's just not enough, right? So
the Sheldons of this world, they're able
to figure out how to program by
themselves, essentially, right? By just
saying, you know, this piece of code is
good. That's teaching by example, right?
This piece of code is good and this piece
of code is bad or we can improve upon, it
it's just not a constructive way. It's
helpful, right, to sharpen the sense of,
and you know, what helped, it sharpens
your review facilities which is an
important part in learning anything. But
really, I think, so in my experience it's
completely crucial to insist that in
your teaching methodology, you teach them
steps that they can actually follow,
right?
Q: True, I agree on that, but in respect
of how many modern software development
teams work and in a code review you can
go, this approach will have this and this
problem, have you thought about doing it
this way, what have you considered, do you
have any thoughts on that process in
teaching people in that process, in that
duration?
A: So for beginners my experience has been
that it doesn't work very well, right?
Q: Okay.
A: That's a, so it's a common educational
point, right, that you need to teach
people, you know there are very different,
many different approaches and we're gonna,
we're going to judge them and we're going
to say "this one is okay and this one is
maybe a little better". My experience has
been with the vast majority of students,
right, is, if you use that as your main
teaching paradigm the problem is, they
produce zero solutions and so it's a much
better idea to really insist on that one
correct solution and you can branch out
later.
Angel: Okay.
Speaker: Does that make sense?
Angel: Thanks.
Speaker: Sorry.
Angel: Mic 1. No, it's okay. Short, quick
questions, please.
Q: Yeah, well, I hope it's a short
question. Thank you very much for the
talk. I'm gonna crush my brains on what
you've told for the coming days. There's
one thing very popular among youngsters:
this is Arduino.
A: giggles Yeah.
Q: It's stick up with C and C++ and you
get very crappy C code.
Speaker: Yeah, yeah.
Q: So how would you put this, what you've
told tonight into the environment of such
a popular platform like Arduino?
A: So I think I would try to make the
teaching languages work on an Arduino. I
think that's gonna be very hard with the
really really small ones but with this
sort of medium sized one, it's a might,
actually be, might actually be possible.
But yeah, as you point out
inhales/giggles, there's a bunch of
crappy C code running on Arduino. I can
see the attractiveness of that approach,
but it's not one that I personally prefer.
Q: Could Scratch fill the gap?
A: No.
Angel: laughs
Q: Thank you very much.
Angel: That was a quick answer. I'm sorry
we're running out of time, thanks for your
questions and thanks again Mike for your
wonderful talk. The applause...
applause
postroll music
subtitles created by c3subtitles.de
in the year 2019. Join, and help us!