35C3 preroll music Herald Angel: Do you remember some days ago, where you sit together with your loved ones and you had to fix their computers? And told them how things work – and why they are working the strange way they are working? Imagine you have to do this for teaching them how to program and give them the passion and the love that you have for programming! So please let's give Mike Sperber a great applause for his talk "How to Teach Programming to Our Loved Ones". Applause Mike Sperber: Thanks so much for that introduction. Let's switch slides back. Speaking of passion. So if you're teaching programming, that's a great ego booster, right? You know that. If your audience is large enough or if you've got super gifted children – like you probably all do – then you know, you could teach them just about anything and they will say, they will tell you and they will give you feedback telling you how wonderful that was. So for example I like functional programming, so that's a lambda which stands for functional programming. And you know whenever I teach that to a sufficiently large audience somebody typically looking like that would come up to me and tell me: "Oh this lambda stuff, this functional programming stuff that's the most wonderfullest thing I've ever heard. And you're a great teacher." And so in the introduction it said something about a couple of days. So I think I've been teaching for 30 years now; in various contexts: to high school students, to university students, to kids, to humanities majors, to computer science majors, to computer science minors, in professional training to co-workers. But if I take the totality of my teaching experience, most of that overall looking back was a failure. And I want to talk about those failures more about the successes that come from the passion. So if you look at initiatives that aim at fostering programming skills among children for example, they always talk about getting people excited and sort of exciting their passion for programming. And you hear politicians talk like that a lot, too. We need to get young people into technology because that is the future. I'm not sure about that personally, but it always seems to end up in classrooms that look like this: That typically have a bunch of robots in there, sold by some company. And that are supposed to, because robots are for some reason inherently interesting. They're supposed to get kids or whomever interested in programming, excited about programming. And that's all good and well. Also I think there's this underlying assumption that only if we would get people excited and interested in programming, they would sort of acquire the required skills by themselves and some process of trial and error or osmosis or something like that. And I think the most prominent project that propagated that notion – some of you may remember – was this One Laptop Per Child initiative a couple of years ago. And you don't … I haven't seen many of those at this conference. And the reason for that is that the educational concepts around One Laptop Per Child were based on this idea of – I think – what's called constructivism. This idea that only if you give children enough material and access to whatever the Internet and teaching materials, then they will all figure it all out themselves and they will figure out how to build programs by themselves. And I think one of the underlying problems – I mean there were many problems with OLPC. But one of the problems was certainly that just this approach to didactics and pedagogy doesn't work particularly well. And you find variations of that pretty much every year. There's an educational initiative built on this notion of inspiring – you know – passion for programming. You know, last year you would hear about a project called Bob which essentially is about programming a little robot-like device, that has blinking lights and things like that. And it's certainly very interesting and you program it by – I think you can see that here – you program it by essentially downloading already … someone already programmed some C++ code for you, and you take some line in the middle and change it to change the blinking through frequency or something like that. And again all that is good and well; and I don't want to denigrate that, but it's all good and well for inspiring passion. But all of these projects have in common is that they are not really about teaching the methodology of programming. And so this is, you know, this is what this talk is about and it's probably going to be the most boring talk you've ever heard. If you want to inspire passion for programming and for computers, there's lots of projects right outside this door – specifically today on the Junghackertag – that will tell you how to do that. The problem is that if you want to transition from these projects to actually serious substantial programming projects that your learners want to undertake by themselves … and if you look closely enough, you will find that a lot of people get frustrated by that experience of writing more complex programs. And even if they do not get frustrated, their code often ends up looking like that on the right hand side. And so of course this entire conference is in the spirit of tinkering and building things by trial and error; and you see a lot of things that look like this. But, you know, in the upcoming IOT apocalypse maybe we want to have a little bit slightly more methodical approach. So the problem is really that most didactic approaches to programming do not work very well. For the longest time I really didn't have a good explanation as to why that was and why maybe the stuff that I was doing or that I learned how to do over the years worked better. And so finally I found a great book that confirms some of my biases, that I read just the day before yesterday – as I was preparing this talk. And it has a couple of … It's written by a cognitive scientist – Daniel Willingham – and he lists a couple of principles that are active when students learn, right? And I think one of the things that's really important is that we all have this idealistic notion that everybody loves to learn, right? But in fact learning is quite a difficult activity and it's quite straining. And – so even though people are curious about things and they love to look at things and they like to have successful learning experiences – if that learning experience means they have to think hard, then at least some people shun those same experiences. Another problem is … so and that's of course a problem when you transition from a primitive programming environment, like Scratch or Bob or something, to more complicated things that you can easily get frustrated, and then shun away from the learning experiences that are required to take the next step. Another one that I found interesting is – so these are just all the cognitive principles in that book – so it's kind of very textual and boring, but I liked it so much. So it says: "Factual knowledge precedes skill." But if you think, so what it means is really that you need to have … that if you want to learn a particular skill, you need to associate that with factual knowledge. But if you think about the factual knowledge that is associated with programming, then a lot of the principles underlying our everyday programming skills are usually unnamed. And they're not really put in specific words, and so they're not in the form of factual knowledge. And which is why a lot of people have trouble with the skill part. I love this bit which says: "Memory is the residue of thought." Which is that we don't always remember the things that we should be remembering, but that we remember things that we spend a lot of thought on. And that means in particular for educational initiatives that are centered around robots – or something that's really … that is supposed to take over the passion part of programming but not really central to the activity of programming – people tend to think about the robots: They tend to think about the motors and actuators and things like that; and those are worthy skills in and of themselves, but they don't contribute much to the actual skill of programming. I remember asking a proponent of such an educational initiative a number of years back, you know what is it? What is the skill that students take away from your robot class? And he said "well, after that class where they spend all their free time for a semester or a year, they really know what pi is. And I don't know for me that is not enough. So another thing is that … maybe that doesn't go so much towards computer science or programming experience but also to the way that we do math education: Is we understand new things in the context of things we already know. In particular we find it easier to understand concrete things. And I think both in math and computer science a lot of explanations are in the form of explaining some abstract thing rather than showing how to do a concrete thing. And so we'll get back. So this is going to be a major point later on. Something that didn't really need saying in that book: "Proficiency requires practice." If you want to get better at programming, you'll need to practice it with the goal of getting better at it. So in the classroom or in a teaching environment you really need to create situations that foster successful practice, the successful solution of problems. So that, you know, this natural curious part in the beginning. So student, so people generally derive a dopamine rush from successfully solving problems. So we really need to put … we really need to put our students in a situation where they can successfully solve problems – that are not too hard and also not too easy, because if they're too easy, the dopamine rush will not be big enough. Here's a trap I think that most people who teach programming know about is that "cognition is fundamentally different early and late in training". And if you're here, most people in this room are late in training. So we've been in touch with computers for a long time, so our cognitive processes when we think about programming are different than the cognitive processes of beginning students. Sometimes that's also called the curse of knowledge. So just because we find some piece of material inspiring or interesting – or some technique of explaining something very persuasive – that does not mean that our students find it similarly persuasive and find it similarly easy to follow along our teaching. If you're teaching big classrooms I think there's being have been a big push towards individualistic learning. And of course that's wonderful. On the other hand our children tend to be quite alike in their style of learning. And so I'm not going be talking about that much that very much today but there's still great value in having a classroom with several students that are all being taught the same thing. Not a subject today but I could also … that that also has been confirmed by my experience. Generally, some people think that you know some people are good at math and some people are bad at math. You know girls are always bad at math for some reason and it turns out that this is … Well first of all it's not true. And even if you feel you're bad at something then usually what we call intelligence can be changed through sustained hard work. I think you know 10 or 20 years ago a lot of people believed in IQ that an innate ability to learn things. But it turns out that that most of the effects of IQ on your ability do things well are quite indirect and through the environment rather than through some structure in your brain that you were born with. And so that's something that you really learn when you do 30 years of teaching is really that your teaching can improve over time. But in order to improve you really must get feedback and you must practice it and get feedback the same way that the skill itself must be practiced. And that sometimes gets you feedback that is surprising sometimes and also it's often quite quite painful because sometimes you get the feedback that you're teaching just did not work. So really, I want to aim a programming education at a diverse audience and not just I mean if you look at the Robot class if you're student population that ends up being in that robot class is really as diverse as you like it as you'd like it to be. I think often that is not the case. So the stuff that I'm going to talk about and then I'm going to talk about has been applied not always by me but to children, to high school students, to university students, professional developers and works quite well. And what it is based on is a set of systematic methods and I'll try to show you in great and painstaking detail what that means. And so here are some references that you can look at. In particular we built on the work of the PLT group in the U .S. led by Matthias Felleisen, who have a great book out now. I'll give you a reference to that later. There is a there's a significant project for teaching high school students in the U.S. and there's also a project that I'm involved with what's called which is called "Dein Programm", which tries to be sort of the little German sister of that stuff. So one aspect that's important to this method of teaching is that all the tools that we use are geared towards learners in particular that means that there is a specific programming environment that was made specifically for learners rather than your Emacs or VI or whatever your favorite thing is that you want to, that you want to inflict on your learners. I don't think you should. I'm an Emacs person myself. So also what it means is that we have … that we use specific programming languages that are derived from real programming languages but that have been modified to be especially suitable for learners. And also then we have something called the design recipes which are a set of methods for systematic program construction that try to provide this factual basis for the methodology of programming. And so there's programming environment … All of this stuff by the way can be downloaded for free. And so there's a great system called racket developed by the PLT group but there's a tiny corner in there that I'm going to refer to today which is great for many things but it was originally designed and still is great for teaching so. So let me try to switch to that. I hope that works out. This moment always scares me. So here is the system called Doctor racket and you can see it has not very many buttons it does not look like Eclipse or Visual Studio or something like that does not look like a professional programming environment. And the way this works is I'm going to try to show you how it works is in the upper part of that window there's just the program that's a text editor with a couple of special features - not very many. And down here is the REPL, which you can use to interact with the program that you've written. I'm not gonna use that very much. But what you can do in the REPL - in the beginning at least - is you can just type something and it will give you … it will then immediately tell you the result of the evaluation of what you typed in. And now you have to remember … This is gonna be alien and strange to you. But the way this works is these languages are based on Lisp. So they use round parentheses a lot and specifically when … always when you want to put something together they have around parentheses and they have the operator in front and - especially if you've been programming for a long time - you think "Oh no, this is … Never gonna get used to that!" but I can promise you, your children will have a very easy time dealing with this. So you could go and say you know you could just type a number and it will give you the result. You would type a string, you know, "Mike". It will give you the result. It … you could go and you could you know, you could combine numbers, right, by adding them together. You could let's do away with that. Looks like this. So that's what it what it looks like a compound expression has always parens around it and the operator in front. So you don't really say you know this number plus that number you say the sum of those two numbers. OK. And so gives me the result of that. What's kind of fun if you're a C programmer or Java programmer this is kind of fun, but children love this for some reason I know. So what you can also do is the same way that you're used to having numbers and strings and whatever and booleans be values. Pictures are also values so that sometimes helps when you're trying to drum up that little piece of motivation that you need. So you could do like a rectangle that is solid blue and that's a value. And whatever whenever there is a value you can write a program that binds that value to a name by writing "define". So you could do something really exciting like this. You would define "pi" for something. We could run that program and then we could put top pi here but we could also do you know "r" that rectangle and whatever 50 solid red and we can run that program. And here's that rectangle. What's maybe more interesting is that we can maybe do another rectangle that's solid blue and you can also see here's the same principle at work right. Parentheses around the define so "define" says it's a definition and the rectangle is just a call to a function that comes with Dr. Racket and it's also in front. And so I could do that. Now I have "r" I have "f2" and I could also do things, things like you know there's for example a function that takes two pictures and puts them beside each other so there's a little jumping ahead a little bit there's a little algebra of pictures in here that you can use to program video games for example later in the class if that's something that you want to do. So this is not entirely without motivational examples. So there's that. Yeah. Let's see how far we can go from there. OK. So but getting away from those motivational examples. In German we are very big on traffic rules. Right. Straßenverkehrsordnung. So there are many rules, right, and we'll try to model that. This is going to make this the most boring talk you've ever heard. So we're gonna categorise German traffic violations. So in particular there's two kinds of traffic violations. There's red light violations where it's important where they happen and it's also important what the duration is. How long after the light has turned red passes before you actually cross the intersection or the red light. And then there's a speeding violation where you also have a place and you just have how many kilometres per hour did you go over the limit. And we want to write functions and I'll tell you how to do that for yielding the place of a violation and classifying a violation as serious or not. And for that purpose we're going to do … use something called the design recipe or rather as there's we're going to use several design design recipes and first of all there's an overall design recipes, which says how you write a function. And please don't fall asleep. There's one, two, three, four, five, six, eight, eight steps to this. And we always ask our students to always go through those eight steps and you think: this is off. I mean I hope you do right. You feel this is this already looks like the most boringest, you know, exposition to programming ever. This is like the German bureaucracy approach to teaching how to program. On the other hand, so, but, you know, it works. That is the point. Specifically each of those steps is something that is small enough so that students can usually successfully do it. And if you can reward it with credit or candy or whatever then you know students will be motivated to get to the next step. You know if you've ever taught unsuccessfully and probably most of you have always taught successfully but what always happened to me is then when my teaching would be unsuccessful my students would be staring at a blank screen. Right. And that would give them this problem and I felt this problem was really solvable and they would give up before typing the first key. Right. They wouldn't know where to begin because there's usually most approaches to teaching how to program are example based. They give you some example. You know, here's that program solves that problem. How here's a different problem, now solve that. And you already saw how that's done. And that process usually or often does not work. And so this fixed sequence of steps gets students over that hump and I'm gonna try to explain that really in painstaking detail because the books don't really do justice to a how bureaucratic and painstaking it is. So you all have the benefit of that. So there's always these eight steps and then there's more instructions that come with each of those steps. Right. But these instructions are eminently learnable and that's the important aspect here. So in particular. So I'm gonna, sort of, jump in right ahead. Oops, oops. Ah. You see something that I don't see. There we go. So if you look at this problem statement. So let me go back one more. So it says the first thing that you do is well you draw a short description of a function we already have two short descriptions of the functions you know find the place of a traffic violation and find out if it's serious or not. And then it says please conduct a data analysis and data analysis means that you look at the entities in your problem and and analyze them. And here it says while this is all about traffic violations. And it says something of the sort. That there's for example a red light violation. And it says that red light violation has place and duration and that duration is in seconds. So one thing that you can do is you can look at the wording of how that data is described and if you discover wording that says you know this thing consists of these pieces. Right. Or this thing has several different properties. This is a phenomenon that we call compound data and that has a special design recipe that PowerPoint somehow threw away. See OK it comes up again. So it says well you recognize compound data by a description of your data that uses words like "consists of" or "has". And then you write a data definition of that form and I will show you how that works. Then, something really trivial comes you count the ingredients and you write a what's called a record definition that's actual code and then you ensure that the counts match and these are instructions in the textbook. Right. And students learn to memorize those instructions and you all going asleep. You know you're all falling asleep. Sorry about that. So let's see where is the right window. Here's the right window. So that's what we were doing. Right. I'm going to leave that here for your entertainment. It says well a red light violation… So excited, I need to talk. And we said it has this formulation that says "has". We're just going to write it down in a slightly more systematic way. So, it has a place and it has a duration in seconds. Right. And that's just a piece of natural language and those semicolons, they make this a comment. OK. So we didn't do much except writing each component of our compound data in a separate line. And then it said - I can't really display it at the same time - then it said, write a record definition and a record definition has this form. It is, it really it looks a little tedious. But it's actually quite valuable. So it says we're talking about red light violations so we give our thing a name. So that's called "red-light- violation" then we will need to create "red-light-violation" objects. So we will need a constructor so I'm going to write down the name of that constructor. Eventually we will need to distinguish red light violations from other things. So I'm going to write something it's a predicate that we'll use a little later and then we have two parts. And I can't emphasize enough how important it is that you sort of remember: two. Right? It has two parts, because it says that there's a place and a duration in seconds and we write the names of things that will extract those pieces. So we go here it says "red-light- violation-place" and "red-light-violation- duration". Or we could, let's call it seconds, so we always know what that is. And now what that does is when I run it is well it doesn't do anything. But what we can do is. We can now create objects that represent red light violations. And so what we could do is… Well let me first show you how it's done. We do "make-red- light-violation". You know there's one in Borg. Somebody who, you know, had a red light violation for four seconds in Borg. Right. And then it will display a record value that shows what the parts are that we had. And so I can copy this up here and call it and make an example out of that. And so like this. So now we have "rv1" here. So this is what's called a constructor and this constructor when we call it creates this object and this object really creates data that is associated with information. So that's an important aspect to explain. And so usually we ask students and I can't I'm not writing this down to explain it to you I'm writing it down to show to you what to expect from students. And so you go "Oh", make them do it. So this is a red light violation in Borg, 4 seconds. So it seems really trivial to you but it's important to really … to link the program to the problem domain that we're in, right. So we have a minor red light violation here. Am I spelling this right? Anyway, so here we go. And one way to talk about this new function that we created "make-red-light- violation" is writing down something that we call a signature. It looks like, sort of like a type signature but isn't quite. That's something that we did specifically for teaching. So you do "make-red-light- violation" and remember in math you would sometimes write f Doppelpunkt, f colon to denote a type. And here we just put the colon in front. So it says "make-red- light-violation". Well it takes a string, that says what the places is, it takes some rational number, that says how long it went, how long the red light violation was over the limit, and it creates a red light violation object. So that's not gonna do much, unless, well let me let me show you something. If I wrote something else here I wrote a number here. Something… Where'd it go? So it's, so it says it gives an error message here. And it's I think it's due to this full screen mode for some reason. Let me see if we can do this again. No, not quite. OK, now we know what it is so. So. Yeah it was. So, when you. Unfortunately it is in German so I hope some of you read German I'll try to translate it says well this program still has to be tested but it says there was a… It says here "Signaturverletzung", which means signature violation. And it says I got five in this line here. And really, so this is the five. Oops, right here in this line. And it violated the signature here. So it gives you… So the system. That's one aspect of what makes the system specifically designed for learners is that it gives you very specific feedback as you run the program. OK. So let's do away with this. Let's get this down here. So now one of the challenges or one of the problems in the problem statement was to write a function that determines whether a red light violation is serious or not. And so when we do that, it said, well, you put a short description in front. And so here's a short description. And there's lots of religious wars about how many comments you should put in a program but to our learners we say put one line not more not less in front of every function. And that's usually about the right level. So is a red light violation serious? So the next thing is. Well if you remember that slide it says, well, if you're writing a function, if you're implementing a piece of functionality, that always ends up being a function in functional programming, you write a signature for that function that talks about what goes in and out of that function. So in this case. Well we have to make up a name for that. So it practically writes itself here and so we just put so in this language you can put a question mark in the middle of a name and you can also put hyphens in the middle of a name. And what we want is we want a red light violation to go in and we want a boolean to come out that says whether that violation was serious or not. So those are already steps in that design recipe that you saw. And so if you're in a classroom situation or whatever you can give credit for each immediate step and you should, because those are already those are all small successes in your programming endeavor. So the next thing that you should do is, you should write examples or tests. Those are almost the same thing here. And so, fortunately we already have examples of red light violations. So we just have to write down how we expect our function to behave with respect to those examples. So there's something called "check-expect" and I hope you recognize that principle that we're, that things are always named in the front. So we could say "red-light-violation- serious?". With children you might want to pick shorter names if they can't type that fast yet, but with grown ups this works. So the first one is four seconds over, so that's pretty serious. So we expect that to be true and that "#t" means true. And so. And you. And the other one is half a second over and that's not so serious under German law. That's fine. OK. So the next step. So now we've written. So let me let me label those things right. This is the short description. This is the signature. These are the tests. And now you write something called the skeleton and the skeleton is just you start writing the function but you already have some information about that function you know the name of that function and you know how many things come in and out. So you write - oops typo here - so and, well, this is a functional language so somebody always has to write lambda somewhere. So when we make a function in these languages we always write lambda. So we want to make a function that accepts one thing and that is a red light violation a red light and we'll just call it "rlv" and we'll just put three dots here. So the three dots I don't mean to say we're gonna fill in the rest later. It means in class when I do this I actually type three dots and in class especially at the beginning we actually ask our students to type the three dots because this is the skeleton. This already gives you credit and it's, you know since this is so easy to do, it really means that there's, you're not staring at a white piece of paper and maybe you feel encouraged to do that next step. Now the next step says you have to fill in what's called a template. And those are elements of the function that you're writing that derive from the data that goes in and sometimes from the data that goes out. In this case the data that goes in is one of those red light violation objects and that red light violation object if you may remember is a compound object it has two pieces. And whenever you write a function that accepts compound data with two pieces you probably need to look at those pieces. So, what you do is, you write you have to write something that will tell you what those pieces are and remember. So I haven't actually told you how that works. But remember here was the record definition, up here, and it told us and we have a signature there that tells us how to construct a red light violation object. And so what we also need is we need a way to get the components out of a red light violation object. So we need what's called selectors or assessors. And those are the things in parentheses here and here and you can also describe them with signatures. And strangely enough so and here a red light violation thing goes in and a string comes out. And in this case, a red light violation goes in and a - what do we say - a rational comes out. So those are of course… Those signature declarations are redundant. You don't have to put them in there. Redundant with a constructor declaration and you're going asleep, you're going asleep anymore... Even more probably than you were. But I had an epiphany in class where I would only write the constructor signature and the students would ask me to also write the excessive signatures. And so they made me even more bureaucratic than I was already by then I already was by nature. So now here what we do is we want to get access to the different parts. So we write "red-light- violation-place" of "rlv". So that's one piece. "-violation-seconds" of "rlv". That's the second part. And those are building blocks. So really if you're really strict about it you might have people type three dots in here also. So these just say, these are building blocks for your function. And so you think about how those parts contribute to the answer to your questions. The question was is the red light cycle violation serious or not. Then you can think about. Well is the place relevant whether it was serious or not. And in Germany I think it's not. But it is relevant how many seconds you went over. So, you then have– then you go through this conscious act of: you've written it down but now you delete it again because you've done a little bit of thinking. And you go and, well, then you look up– I look this up on the Internet. If it's over one second then – or if it's one second or over – then it's serious, and then you delete all the ellipses and make sure all the parentheses close and then you run the program. And here's still the signature violation that we need to fix. So it says here again there's a little German sentence because these languages were designed for Germans and it says: both tests were successful, because we wrote two test cases here. OK. So this bureaucratic approach just goes on and on. So I'm just going to go through the second iteration more quickly. So it said you know what did it say. It said, it said this. We also have a speeding violation. So let's go through the motions of that: a speeding violation has– again, it also has a place and it has, you know, how many kilometers per hour over. And we write a record definition something like this, and we could do, you know, two speeding vio- so now we have a data definition that says: oh we've got two components, we've got a record definition that needs to match that. You all think this is trivial but with compound data our students often have trouble. So it serves you well to remind them that there's two pieces, and those two pieces need to be selectors in the record definition. So we have speeding violation one, speeding violation on Main Street. You know what, 20 kilometers over, and we have another one, you know low street or whatever, that is 25 kilometers over. So that is two examples right. And we have one on low street, 25 kilometers per hour over limit. So once again the speeding violation constructor has a little signature that says well a natural number goes in, speeding violation object comes out. And so we go through those same notions. I need two things in order to demonstrate one more thing. So then again the question was: When is a speeding violation serious? And of course a speeding violation goes in and a boolean comes out. And so we will write two tests. So speeding violation in Germany is serious when it's 21 kilometres an hour over the limit, or over that. Right. And it gets progressively more serious after that. So. So the first one is not too serious. We'll not get you any points in Flensburg. But the second one is. And once again we go right, speeding violation serious, we write the skeleton. So then we write the skeleton, then we fill in the gaps and says we really should be writing calls to the accessors. So we have the place of the speeding violation and we have the kilometers over of the speeding violations. And then we think a little bit and then we realize: oh the place does not matter. So I'm skipping. Of course this all goes on usually over a longer period of time that you're teaching. I'm going I'm going pretty fast here. So we do away with that and we go well this really if this is over 21 then that's bad. Okay. So let's see if that works. It says km per hour over– So then it says all four tests are passed. So that's good. So you know there is primitive data, there's compound data. You may have noticed that on the slide it said: a traffic violation is either a red light violation or a speeding violation. So that's not compound data. When you see this formulation in your language that says: it's this or that or that or that, or maybe it is one of the following. Then you're not looking at compound data, you're looking at a phenomenon called "mixed data". So you've seen this, you've seen this, you've seen this mixed data. So you recognize it by either the words "or" or "one of" and you write a data definition that really has that form, you count the alternatives just like you do with compound data. You write a signature definition. I'll show you how to do that. And you ensure that the counts match. And so the way that you do that is this. We said data definition, so we said: a traffic violation is one of the following. It's either a red light violation or it is a speeding violation. And just as with the compound data this little data definition has some code that goes with it. So we'll just call this thing a traffic violation and we just use define to say what that is and define traffic violation, is it just a signature that says it's mixed, it's mixed data from red light violation and speeding violation. So here you go. So now we can use that in signatures. You remember the problem statement didn't say: find out whether a red light violation was serious or a speeding violation was serious, it said: find out whether a traffic violation is serious. So you know it is a traffic violation, but so far we only have functions, one works on red light violations, the other one works on speeding violations, but they don't work on that mixed. So we'll try to do that now and instead of writing red light violation we'll just write traffic violation to boolean. So we could now write tests that match those that are there but I'll spare you that. But in class we absolutely would need to do that. And now what we do is, when we have a traffic violation– Remember how I said if you have compound data, you put calls to the accessors in the body, and then you go on from there. But now we're looking at mixed data in the input. So mixed data has a different template and that template says: well if you're looking at mixed data, maybe this or that or that, you should probably find out what that is before you do anything else. And for doing that we use a conditional we use something like this– So what we need to do is we need to distinguish red light violations from speeding violations, so we need some function that will tell us which one it is. And this is the last bit up here in the record definition. You remember that we said red violation here, red light violation here. This is the name of the constructor, so it is the constructor. These are the accessors. And this is what's called the predicate, and the predicate tells us whether a thing is a red light violation or not. So in this case the predicate says: red light violation question mark, or "p" is what the programmers in these languages say. And it takes anything and it tells us whether it is a red light violation object or not. I'm just gonna copy that down so that we remember. We're almost done. So of course the same thing goes for speeding violation. So we need a conditional that has as many branches as we have alternatives in the data definition. And again you think this is super trivial and childish, but it works very well for making successful programmers. So we need two branches, and the way that works is this. So you write this out with ellipses, and then you need to come up with tests for the two branches in this case the tests are: is something a red light violation or is it a speeding violation. So we have this, question mark tv, and we have this which says, speeding violation tv. And now here we just need to put in the answers, and the great thing is we already have the answers we already have two functions that tell us whether a red light violation is serious and so we can just call that here and we can do this here so and then we're done. So I think that's all we can do in this hour that we have today. So I hope you see two things. First of all this is super boring and super bureaucratic. But maybe you can see that every single step that we have here has is a principle that has a specific name and that you can explain in very specific concrete terms that are not abstract. And that means it can really explain every step that's needed to solve this problem. And I can't tell you what a game changer to that is for teaching. If you really ask yourself if, you know, when you when you present an example to your students whether you can really explain every single step and explain to the students here's what you should have thought, you know, here's how you should have picked what to do next. That usually ends up badly. So so one of the principles behind this style of teaching is really to be absolutely sure every single step that you expect your students to make when they solve a problem has a name and has been explicitly taught in your class. So every technique has a name. You noticed me saying compound data and mixed data and design recipe and template and skeleton. And so this is the factual knowledge that we use that precedes the skill that we want to then induce. If you're teaching a class that has rewards you reward every single step. You really insist on form. I also can't stress this enough so on our home page you find a paper that says form over function. We don't accept any program that is correct. We just accept the ones that match the form that you've seen. We also measure success. You know you really need to look at how well your teaching style is doing and you improve it continuously. So those are the important principles. You might think that this stifles creativity. And I really don't think that's true. And I think that is based on a misguided notion of creativity. So if you talk it successfully creative artists they really also rely on a set of named techniques that they use to tackle a creative problem. And so somebody always says Mozart you know Mozart never had to learn or practice before he got to be a great composer but Mozart started it so early in childhood that he had his 10000 hours of practice in there to be before most people even start. So this works for. So this has been proven to work this approach for children. I think I would start about 11 years, beginning programmers. It's worked for programmers that had learned some other via some other approach you know bad habits and professional developers. There's two websites that you can go on to get more information. One is our American sister project called programmed by design that has lots of material, links and publications. The DrRacket software that I showed you. And there's also a book in English how to design programs. And it doesn't say that here but that book is available for free online but there's also a print version. And similarly if you're looking for German language material there's "dein programm DOT de" which also has links and publication, links to the same software. And the draft version of that book is there too. And hopefully we'll have a print version of that also next year. And that's all I have for you today. Thank you very much. Applause Herald angel: Thank you Mike for that talk. If you have any questions, we do have the microphones lined up here in this row and in that row and does the signal, yes the signal Angel has a question. Signal Angel: Yes, so one IRC user asks what are the benefits of using this DrRacket tool instead of for example Python which was also developed for teaching? Mike: So Python is definitely not developed for teaching, not in any meaningful way. So in practice, in practice I think the fundamental diff-, so but there's a lot of educational initiatives around Python. The thing is really that if you try to name and really formalize the techniques the systematic techniques that I showed you and apply that to Python programming you will find that very hard. I personally found it impossible. Most Python programs out there in practice are just not developed systematically and I don't know how to do that. And so that is where that is much better. This corresponds to these programming languages were designed in lockstep with the didactic principles that underlie them and as far as I can tell, I'm sorry about that, Python was not developed with any didactic principles in mind whatsoever. Sorry. Herald Angel: OK then. Microphone 2 please go now. Questioner: I teach roughly 14 years olds in the middle school and also programming and I use the App Inventor right now. The App Inventor, MIT Media Lab App Inventor, I […] with scratch and I'm not sure you, you said okay you need to buy Lego Mindstorms robots and stuff like that or scratch or MIT App Inventor. That's not the case. Mike: No. Yeah. Questioner: And what I find difficult for the students I have there they are not the best from the best parents, then they would like to show something in the end. And it's your program looks a lot like Mike: Superball! Questioner: it is really very boring and laughter how do you bring it over that point? I find it so valuable that in the end they can show it on their smartphone. Mike: Yeah, depending on your target audience of course you choose different examples and this example just had a lot of things. You might have seen me show the pictures, show the picture algebra at the beginning. So that's something that tends to work great for children and older children alike and that scales all the way to writing video games and there's an entire book that shows children or young people on how to do that. So that's one of the great aspects of this. I think that's a fundamental difference to things like scratch and so on this approach to programming scales all the way to programm-, to professional programming and it scales to substantial video games. So the students that we so we always used to do that the halfway point in the first semester at the university and they were able to write a complete like 80s style you know frogger or snakes or something like that that looked pretty fancy. And that's something I think that your children could take home. Herald Angel: OK. Then microphone 1. Questioner: Hi, thanks for your talk. I'd like to know so your approach adds a lot of let's say overhead that is also necessary to be taught. How do you go about the methodology in the actual classroom though. Yeah. Do you al-, do you also have some recommendations on how to tackle the actual design of the of the class, what methods do you use, do you use a flipped classroom or what do you do? Mike: A good point. So so mostly the classes that I have taught they are taught just like what I did just now. So I try to demonstrate that to really make that clear because it hasn't really been documented. I could refer you to friends of mine who have taught a flipped version of that which also seems to work quite well. But the important thing really I can't stress this enough that as a teacher and I skipped a couple of corners just now to fit in the time slot was that you go through all of those motions that you always go through all of that motion and that's a great tool not just for giving every single step a name but also for pacing the classroom and that and the rest kind of tends to fall in place has been my experience, right. No matter whether you're looking at you know beginning students or professional programmers. I'm not sure I answered your questions but maybe you can take the rest offline. Herald Angel: Thank you. Microphone 3 please. Questioner: Yes. I think this is very great but it is teaching functional programming and many people will very soon need imperative programming. How do you do the switch or can you do it? Mike: So I I would dispute that but. Laughter Questioner: Well if you want to get paid for it. Mike: Thank you, go, go. Laughter Mike: So I run a company that does all their software projects doing functional programming. Ultimately you will need to talk about effects. The thing what this does really is I mean if you're writing software professionally you know no matter what the language is, large parts of that should be functional. So this is a great way to teach good programming discipline and a lot of programs out there don't show good programming discipline. So I think this would be great to improve upon that. So what this does is it pushes the boundary. To be honest I have no idea how to teach systematic development using imperative languages. I don't know how to do that. I don't know how to do it and I don't know how to teach doing it. On the other hand what I can do that do here is I can push the imperative parts of the programming to the fringe and make them less important for the success of my project and for the structure of my project. So yeah. So you should. This is the good thing because we know functional programming works well and we know it is a good foundation for an educational discipline. And yeah I can't, I mean there are there are various courses that build up upon this, but ask me offline about that that tackle that imperative programming. Herald Angel: OK then microphone 4 please. Questioner: Yeah I'd like to thank you for your talk too and I'm curious what's your experience how many repetitions do you need to teach your students until they settle with the principles. Do you teach like three examples or is it up to 10 examples? Mike: I'm not sure I have a solid rule for that. So my experience has been, so I think every principle here usually has like two in class examples at the university level and then has maybe three or four examples where they do exercises and that's usually enough but your experience might vary. I don't I don't think I have a good rule for that. Generally you might not have gotten for this but so the point of comparison and where I have the most experience is at the university level. Overall the progression of material in here is really really fast compared to your traditional Java course. So you can cover a lot of material using that. I'm not sure how many how many university students or university courses have successful video games in the middle of the first semester and there are nice programs that are well structured so so surprisingly maybe even though this is so boring and tedious it allows you to write programs successfully quite fast and also goes to lots of teaching to go quite fast. Herald Angel: OK. Microphone 2 please. Questioner: Hello, thank you for your talk. When I learned programming as a kid quite young and I think that I could transport tools and the mindset also to mathematics and full blown problems. Mike: Yes. Questioner: So I just wanted to ask if in your experience can children also use this systematic way of solving, I mean do they really make this transition? Can, are they getting better at solving problems? Mike: Yeah absolutely they do. So if you look at one of the three projects I listed was the Bootstrap Project which is which is aimed at high school students or middle school students and there the approach is specifically tied to the algebra part of mathematics and so this is where you'll find exactly what you're looking for. And that's been that project's been usually successful and they have lots of material on how it should be taught. So that's great stuff. Herald Angel: Okay, we have two more minutes and two questions. So Microphone 1 please. Questioner: Hi. How do you measure success in your teaching? Mike: So mostly at the university level we look at the final exams and we have a few papers out that are referenced from the web page there. That's I mean usually what we do is we have pretty close supervision, even at the university level. So we look over students' shoulders all the time to make sure that we're teaching them at the appropriate level and at the appropriate pace. But over the years we've seen measurable improvements by looking at the final exams and very specific ones. So we don't just look at the overall grade we look at individual problems and see all the progress has been and what we expect and there's papers out on that. Herald Angel: And micr ophone 4 please. Questioner: Is there some kind of auto completion in your editor or do you not advise us to use this feature for beginners? Mike: Laughter. No there's not auto completion as far as I know. I'm not sure I would advise against it. I know that my American colleagues they've I mean as you've noticed write the templates as it's sort of always recurring program elements and you could imagine there being a button that inserts that program fragment and our American friends they experiment with that and they came out not using that in practice anymore. But I can't tell you details on how that is. But if you're interested you could send me email and I could find out. So for some reason so I can't tell you why and I'm not I'm not ideologically opposed to that but we're not doing that. Herald Angel: OK then. Mike thank you for that very enlightening talk and become a big applause for that talk. Mike: Thank you very much. Applause postroll music Subttitles created by c3subtitles.de in the year 2019. Join and help us!