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