34C3 - Growing Up Software Development

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!