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