 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 Sperve a great applause for his talk, how to teach programming to our loved ones. So if you are teaching programming as an ego booster, you know that. If your audience is large enough or if you've got super gifted children like you probably all do, then you can teach them just about anything and 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 whenever I teach that to a sufficiently large audience, somebody typically looking like that would come up to me and tell me this lambda stuff, this functional programming stuff, that's the most wonderful 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 coworkers. 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 in 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 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 the tactics 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 could 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, somebody's already programmed some C++ code for you and you take some line in the middle and change it to change the blinking 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, all 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, if you want to inspire passion for programming and for computers, there's lots of projects right outside this door, specifically today on the Junghack Attack 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 work better. 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 cognates or written by a cognitive scientist, Daniel Willingham, and he lists a couple of principles that are active when students learn. 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 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 going to be 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. 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 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, and 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 to this. This is going to be a major point later on. Something that didn't really need saying in that book, proficiency requires practice. So if you want to get better at programming, you 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 this natural curious part in the beginning, so people generally derive a dopamine rush from successfully solving problems. So 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 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 been a big push towards individualistic learning and of course that's wonderful. On the other hand, children tend to be quite alike in their style of learning and so I'm not going to 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 also has been confirmed by my experience. Generally, some people think that 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 innate ability to learn things, but it turns out that most of the effects of IQ on your ability to 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, well, surprising sometimes and also it's often quite painful because sometimes you get the feedback that your 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 your student population that ends up being in that robot class is really as diverse as you'd like it to be, I think often that is not the case. So the stuff that I'm going to be talking about, that I'm going to talk about, has been applied not always by me, but to children, to high school students, to university students, to 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 of 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 Feliz and we have a great book out and I'll give you a reference to that later. 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 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's 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 inflict on your learners. I don't think you should. I'm an Emacs person myself. So also what it means is 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 this 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 let me try to switch to that. I hope that works out. This moment always scares me. So here's 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. It does not look like a professional programming environment. And the way this works and I'm going to try to show you how it works is in the upper part of that window there's just a 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. We're not going to be using 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 immediately tell you the result of the evaluation of what you typed in. And now you have to remember this is going to 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 always when you want to put something together they have round parentheses and they have the operator in front. And especially if you've been programming for a long time you think oh no, I'm never going to get used to that but I can promise you your children will have a very easy time dealing with this. You could go and say, you know, you could just type a number and it will give you the result. You could type a string, you know, a mic, it will give you the result. You could go and you could combine numbers, right, by adding them together. You could, let's go away with that. It looks like this. So that's what it looks like. A compound expression is always parenza 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, okay? And so it gives me the result of that. What's kind of fun if you're a C programmer or a Java programmer? This is kind of fun but children love this for some reason. I don't 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 whenever there's a value, you can write a program that binds that value to a name by writing define. So you could do something, you know, really exciting like this. You would define pie for something. We could run that program and then we could put top pie 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, you know, that solid blue. And you can also see here's the same principle at work, right? Parenthesis around the define. So the define says it's a definition and the rectangle is just a call to a function that comes with Dr. Rackett and it's also in front. And so I could do that and now I have R, I have F2 and I could also do 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, but there's a little algebra of pictures in here used 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. Okay. So, but getting away from those motivational examples. In German we're 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 going to categorize 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 kilometers 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, we're going to use several design recipes. And first of all, there's an overall design recipe which says how you write a function. And please don't fall asleep. There's one, two, three, four, five, six, eight steps to this. And we always ask our students to always go through those eight steps. And you think this is all, I mean, I hope you do, right? You feel this already looks like the most boring is, 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. And basically 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, or here's a different problem and I'll 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. Try to explain that really in painstaking detail because the books don't really do justice to how bureaucratic and painstaking it is. So you'll 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. 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 do 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 analyze them. And here it says, well, 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 a 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. Let's see. Okay, 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 definition, a definition of that form and I will show you how that works. Then something really trivial comes, you count the ingredients and you write what's called a record definition, that's actual code, and then you ensure that the counts match. And, you know, these are instructions in the textbook, right? And students learn to memorize those instructions. And you all, you're all going to sleep, you know, you're all falling asleep, but sorry about that. So let's see, where's 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. I'm so excited, I need to talk. And we said it has this formula and it says has. And 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, okay? 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 the record definition has this form, it's really, it looks a little tedious, but it's actually quite valuable. So it says we're talking about red light violations. We give our thing a name. So that's called red light violation. 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 that'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, well, let's call it second, so we always know what that is. And now what that does is, when I run it, 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 Bork. Somebody, you know, had a red light violation for four seconds in Bork, 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. And 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 Bork. Four seconds. Four seconds. So it seems really trivial to you, but it's important to really 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. And it looks 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, f colon to the noted 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 place 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 going to do much. Unless, well, let me show you something. If I wrote something else here, I wrote a number here. Something, where'd it go? So it says it gives an error message here. And I think it's due to full screen mode for some reason. Let me see if we can do this again. No, not quite. Okay, now we know what it is. Yeah, it was. Unfortunately this 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 signature violation. And it says I got five in this line here. And really, so this is the five 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. Okay, so let's do away with this. Let's get this down here. So now one of the challenges or one of the problems and 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 are lots of religious wars about how many comments you should put in a program about 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 and 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 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 were, 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 grownups this works. So the first one is four seconds over so that's pretty serious. So we expect that to be true and that hash mark 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. Okay. So the next steps, so now we've written, so 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. You know how many things come in and out. So you write, oops, type we're 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. 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 going to 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 accessors. And those are the things and parentheses here and here. And you can also describe them with signatures. And strangely enough, so in 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 did we say, a rational comes out. So those are, of course, those signature declarations that are redundant. You don't have to put them in there redundant with a constructor declaration. And you're going to sleep, you're going to sleep even more probably than you were. I had an epiphany in class where I would only write the constructor signature, and the students would ask me to also write the accessor signatures. And so they made me even more bureaucratic than 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, violations 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 question. So the question was, is the red light violation serious or not? And 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 have, 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, and we can, so it says here again, there's a little German sentence, because these languages were designed for Germans. So it's both tests were successful because we wrote two test cases here. Okay, so when 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, 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 violations. 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, 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, you know, 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 these are just 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, 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 the speeding violation serious? Is the speeding violation serious? And of course, the 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 kilometers an hour over the limit or over that, right? It gets progressively more serious after that. So the first one is not too serious. We'll not get you any points in Flensburg. But the second one is. So, and once again, we go write 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. So 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 kilometer hour over. So then it says all four tests are passed. So that's good. So, you know, there's 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 off and you write a definition, 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 make sure 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 call this thing a traffic violation and we just use define to say what that is and define traffic violation is just a signature that says 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 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. And 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 it may be 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 this 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 programs 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 going to copy that down so that we remember. Well 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 so the good... And now here we just need to put in the answers and the great thing is we already have the answers. We 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 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 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. Here's how you should have picked what to do next. That usually ends up badly. 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 will notice 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 really need to look at how well your teaching style is doing and you improve it continuously. So those are the important principles. I 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 at successfully creative artists they really also rely on a set of name techniques that they use to tackle a creative problem. And so somebody always says Mozart. Mozart never had to learn or practice before he got to be a great composer but Mozart started so early in childhood that he had his 10,000 hours of practice in there 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 have 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 Program by Design that has lots of material, links and publications. The Dr. Rackett 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 dyneprogram.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. Thank you Mike for the talk. If you have any questions, we do have the microphones lined up here and this row and that row. And does the signal... Yes, the signal angel has a question. Yes, so one I assume user asks what are the benefits of using this Dr. Rackett tool instead of for example Python which was also developed for teaching? So Python is definitely not developed for teaching. Not in any meaningful way. So in practice I think the fundamental difference... 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 but it's much better. 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. Okay, then microphone too. Please go now. I teach roughly 14 years old in middle school and also programming and I use the App Inventor right now. The App Inventor, MIT Media Lab App Inventor. I started out with Scratch and I'm not sure... you said, okay, you need to buy Lego Mindstorm robots and stuff like that for Scratch or MIT App Inventor. That's not the case. No, not the case. What I find difficult for students I have, they are not the best from the best parents that they would like to show something in the end and your program looks a lot like Super Best School. It's really very boring and how to bring over that point. I find it so valuable that in the end they can show it on their smartphone. 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. That's something that tends to work great for children and older children alike and that scales all the way to writing video games. There's an entire book that shows children or young people on how to do that. 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 professional programming and it scales to substantial video games. The students that we... We always used to do the halfway point in the first semester at the university and they were able to write a complete 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. Okay, then microphone one. 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? Do you also have some recommendations on how to tackle the actual design of the class? What methods do you use? Do you use a flipped classroom or what do you do? 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've taught a flipped version of that which also seems to work quite well. But the important thing really, I can't stress this enough, 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 the rest kind of tends to fall in place has been my experience, right? And no matter whether you're looking at beginning students or professional programmers. I'm not sure I answer your questions but maybe you can take the rest offline. Thank you. Microphone free please. Yes. I think this is very great but it is teaching functional programming and many people will very soon read imperative programming. How do you do the switch or can you do it? So I would dispute that, but... Well, if you want to get paid... Yeah, thank you. 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 if you're writing software professionally 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 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. This is a good thing because we know functional programming works well and we know it is a good foundation for an educational discipline and there are various courses that build upon this but ask me offline about that that tackle imperative programming. Okay, the microphone for please. 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 are settled with the principles? Do you teach like three examples or is it up to ten examples? 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 think I have a good rule for that. Generally, you might not have gotten for this 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 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 surprisingly maybe even though this is so boring and tedious it allows you to write programs successfully quite fast and also allows the teaching to go quite fast. Okay, microphone to please. Hello, thank you for your talk. I learned programming as a kid quite young and I think that I could transport the tools and the mindset also to mathematics and problem solving. So I just wanted to ask in your experience can children also use this systematic way of solving do they really make this transition? Are they getting better at solving problems in mathematics? So if you look at one of the three projects listed was the Bootstrap project which is aimed at high school students or middle school students and there the approach is specifically tied to the algebra part of mathematics so this is where you find exactly what you're looking for and that project's been usually successful and they have lots of material on how it should be taught and that's great stuff. Okay, we have two more minutes and two questions so microphone one please. Hi, how do you measure success in your teach? So mostly at the university level we look at the final exams and we have a few papers out that are referenced from the webpage there. Usually what we do is we have pretty close supervision even at the university level so we look over students' shoulders all the time that we're teaching them at the appropriate level and 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 how the progress has been and what we expect and there's papers out on that. And microphone four please. Is there some kind of auto completion in your editor or do you not advise us to use this feature for beginners? 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 right the templates is sort of always recurring program elements and you could imagine there being a button that inserts that program fragment and our American friends they experimented 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 an email and I could find out. So for some reason, so I can't tell you why and I'm not ideologically opposed to that but we're not doing that. Okay, then Mike thank you for that very enlightened talk and give him a big applause for that talk. Thank you very much.