Programming is Writing is Programming

Good morning everyone. Thanks for being here at 9ine after the party. I know it must be tough. My name is Selina. I'm assistant professor at Dela University of Technology. I'm on Twitter as well. So if you're tweeting about this talk, you can mention me so I can see all the nice things that people think about this talk. We're going to talk about programming and writing today. But this first, who knows who said this? Everyone should learn programming. Yes, every programmer ever. Don't you agree? I mean, we all love programming. So, I'm sure all of you at one point have said everyone should learn programming. Kids should learn programming because it's really important. But that of course leads to the question, what is programming? It it's a huge thing. And if you say everyone should learn programming, what exactly is it that you mean with the words programming? And this reminds me of of one of my favorite jokes where you have this old fish. He's swimming and he meets two little young fish and he says, "Hey folks, how's the water?" And the little fishies say, "What's water?" They don't know what water is. They're in water. The only thing they know is water. A fish has never been in air. So, he doesn't really conceive water as a thing. It's just everything that's there. And I think for some people in programming it's also like this. The only thing we see is programming. So what it actually means to people that are not programming that are in the air is very very hard for us to get a hold of. Let's go back a little bit because I'm going to share some personal stories here. Let's go back to the year 2008. This is when I started grad school and I moved from Antova in the tiny tiny country of Netherlands to Delft which is about 100 kilometers in distance probably super impressive here but for us it's really on the other side of the country and I went to work at the Delft the university I'm still working at and my research assignment there was to build a DSL a domainspecific language for finance so a programming language specifically designed for financial institutions and me and my supervisor we envisioned something like this a programming language in which financial experts could express their domain in a way that's readable to them something like if we if the interest is too high we have to sell this or something like that so I started an internship at an insurance company so again I was just starting grad school I was still young I didn't really know lots about the world and what they taught me in university was more or less this there exist users ers and there exist programmers and there's a huge wall in between them with a little little hole through which they sometimes communicate a little bit there are users and the programmers and users use and the programmers program that's more or less the view I got when I was in university however reality when I started this internship in the insurance company was somewhat different I found out that all the people program also users normal uninitiated human beings can do some programming. The people that were experts, insurance experts, accountants, people like that, they were absolutely programming. However, they didn't use a programming language as most people define programming languages because they were using spreadsheets. This was their programming language. So, I went back to the university, went back to my supervisor. said, "Man, they don't need a DSL in finance. They have a DSL in finance and it's called Excel. This is a programming language that works for financial experts. It's a language they understand. Spreadsheets are code." And this became the motto of my PhD dissertation. Spreadsheets are code. Spreadsheets are a way, a means of expressing a program for people that aren't necessarily self-identifying as programmers. And not only are spreadsheets codes, they are functional codes. Because think about it, a formula in a spreadsheet, the only thing it can do is reference other cells and calculate a new value based on the references. So spreadsheets by definition are side effect free because the only thing they can do is change their own little cell. Even more so if we're talking about busword, spreadsheets are also reactive programming because a cell is updated when the cells it depends on are updated and it's not the case that the entire spreadsheet is recalculated. So it's a reactive functional programming system that's used by 750 million people. Isn't that remarkable? So spreadsheets are code as I said was the motto of my PhD dissertation. It's research that I've done for a number of years around the idea that spreadsheets don't really have an IDE. If you look at Eclipse or Visual Studio, those are systems made to support you in programming. They help you understand source code. There are lots of features in an IDE that help you understand source code. For example, visualization, but also smell detection and refactoring support. all sorts of features that make you write better source code. And if you look at a spreadsheet and often it's not just one worksheet but a collection of worksheets that are all connected with each other. How do you understand that? How do you measure the quality of that? And one of the core ideas that I explored is code smells. Code smells as originally defined for object-oriented languages. For example, a very long method is a code smell. It might be functioning perfectly fine. However, because it's very long, we know it's hard for people to understand. And another code smell is a method with lots and lots of parameters. Might be perfect. However, if it's so many parameters, it's very hard to understand. And those code smells really nicely relate, for example, long methods, but also duplication, code clones. they really nicely relate to spreadsheets because a long method if that's smelly then a long formula is also going to be smelly and if you have lots of clones in your source code and that's bad then if you have lots of duplication in the formulas of your spreadsheet that's going to lead to similar maintenance issues so I wrote a number of papers about detecting code smells in spreadsheet formulas refactoring spreadsheet formulas to increase quality of spreadsheets and also detecting clones phones in so duplication in formulas and this eventually made me a a real PhD now I'm a proper academic graduated on the topic of spreadsheet analysis and this story is sort of the the happy story that I've told many times at conferences hey spreadsheets are code and it's awesome and smells and refactoring and tada everyone's happy so it's sort of the story of my brain it is what really happened it's not fake news it actually happened like this. However, it's only maybe the upper layer of the story because there's also the story of the heart. And during this period, things were happening to me that weren't super happy. So, look at me. This is 2010. I'm very happy. I'm eager. Like I'm this morning, I'm like, "Oh, spreadsheets are code. Everything is awesome. I'm going to conferences like this and telling people that spreadsheets are code." And then people said this all the time. spreadsheets aren't real real programming. It it's programming, but it is not real programming. It is too easy. And I'm like, yes, but they're they're functional programming. And you actually know the whole rant I just did like, oh, awesome. Yeah, it's still not not real programming because it doesn't it doesn't fit our world. It cannot be programming because everyone can do it. So, it cannot be programming. This is it doesn't fit our view. And this continued for a while for for a few years and people keep saying kept saying sheets it's not it's not real and after a while it really wears you out. I mean it's sort of it's fun to be the underdog and to change people's mind for a while but after 10 years you're still trying to explain people that what you're doing is actually really important to many people and people keep laughing in your face if you say my PhD dissertation is about spreadsheets. it doesn't do nothing with you. It so after a while I didn't really really realize I wasn't into it anymore but it sort of happened that I went out to do other things and and this is my reflection now that contributed to that. So what happened a good thing is I was sort of heartbroken and I didn't really know what to do and then through networking I ran into a community center in my neighborhood that needed a programming teacher. They said every Saturday can you come in to teach us kids some programming? I'm like, "Yeah, I can do that. I know programming, so I'm sure I can teach it to eight-year-olds. That'll be totally fine. Even though I have zero experience, this is what having a PhD does to you. You think I am smart in one thing, so I am smart in all the things. I can do that. This this will be easy." So, in the community center, they had a Lego robot, a Lego Mindstorms robot. Who has programmed Lego Mindstorms? Cool. Like to test it for your kids, right? Not for your personal enjoyment at all. So they had this Lego robot and it's a system that you program in a visual way. It looks more or less like this. So you have little blocks and you connect them with wires to to rotate the servos or to read a sensor and to act based upon that. And of course when when the kids went home I was not playing with the robots. I was looking at their programs and I was like, hm, I've seen this before because those programs a little bit like these pictures, they weren't really necessarily very well structured. There was some duplication in these programs. There was some unnecessary connections. I'm like, hm, this looks like goat smells in Lego Mindstorms. This is exactly the same type of patterns I saw in the spread in the spreadsheets, I also saw in the children because like spreadsheet users, all novice programmers, including kids, they're very goal driven. They just want the machine to work. They want the robot to run and if they've achieved that goal, they're done. And then they move on to their next assignment. Like an accountant is making a budget and if it works, they're happy. The their goal isn't programming. their goal is their own job or their own hobby. So we saw very similar code smells and I was talking with a colleague in the US that had also done some research into the programming language kodu. It's a Microsoft programming language also aimed at children and we saw similar patterns there as well. So I thought hm maybe I'll just write one little program about Lego Mindtorms code smells. I I was not at all at that point aiming for a change of direction. And I just thought hm I saw this interesting thing on a Saturday so let's just write it down because I'm a scientist and I can do that. But of course you know you know with 10 minutes in this talk this is not going to be the only favor about this topic because then I started wondering of course is it that bad? Our code smells bad does it matter to novice programmers if their programs are really smelly? Because contrary to traditional software and contrary also to spreadsheets, maybe those programs don't really stay alive for a very long time. So if they're bad, then maybe it doesn't matter. If they're small, maybe it doesn't even hamper understandability of kids. So this is when we moved on to a programming language called Scratch. Who's used Scratch? It's so cool. It's a visual programming language. It's made by MIT. It's it's free and open source. We'll see some examples of how it looks like later. and it allows kids to program games and animations in the browser. It's really easy. You don't have to install anything. It just runs in the browser. We did an experiment with these are fresh kids. I wasn't working in the community center anymore because you can only experiment on children for so long. So, we had 61 high school kids in the Netherlands that we randomly divided into three different groups. One group got nice, perfectly designed scratch code and one group got code that had lots of duplication, repetition, similar blocks in different places and one group got long methods. So all the blocks together in one script and we gave them a game like a breakoutlike game in Scratch and we asked them to explain the game what is happening in it and also to adapt the game to make little changes to it and then we could measure whether the nice group did it better or differently than the two smelly groups. So question are smells bad? Short answer is yes. Code smells are bad also for kids, also for novice programmers that just learning it. If you make a program that has lots of duplication, it will harm their understanding. The nice group, the nice group did better on the assignments of explaining and adapting the source code. So h maybe two papers, maybe one little paper, one more code smells are bad also for programmers. But then of course you start wondering and people ask you like oh yeah you're researching code smells in Scratch but does it actually happen? Is this purely your new academic hobby or is this a thing that occurs? Then we wanted to know are code smells common in Scratch. Is this something that happens in in the field in the wild or is this just something that we invented and put it in these programs? So what we did is we downloaded 250,000 programs because Scratch is not only open source. It also has a repository in which children can share their programs and all the programs that are shared are Creative Commons. So you can do everything with them. You can play them. You can change the programs if you want to. You can print the source code out or have it tattooed on your back or you can do some static source code analysis on it which of course is the most desirable of those options. We downloaded 250,000 programs and we found that 30% of the programs suffers from long method smell. So that's quite some programs that are nonwell structured and we knew from the previous study that this will hamper understandability and as I said there's a public repository. So these programs do get shared. Programs that are on the homepage sometimes get thousands of views and thousands of remixes. So gets take like forks. You take them and make them their own. So they are exposed likely to bad source code with long method and 26 of percent of the programs had duplication. So this is something that's bad and we also know it's common. Something else that we found in this study, we weren't really looking for it. We were looking for code smells. A very surprising finding that I will talk about more in the remaining of my talk is that about half of the programs only had interaction. So half of the programs did something like if you press a button, if you click the mouse, if you make a sound and the other half had no interaction whatsoever and this this is water of programming like stuff because I was thinking Scratch is for games. What kids are making are games. So there must be interaction. So this finding was like hm this this is weird. I don't really know how this fits in my mental model of what programming is. But we will come back to that finding later. Of course, there was another paper. We then figured out how kids code and how we can analyze the source code. I then wanted to know, can we teach code smells? Because we know it's bad, we know it's common. What can we do against it? Can we educate kids to understand code smells? Can we educate kids to not make code smells even? So what we did is we created an online course on edx.org where we explained children's scratch and about 3,000 kids participated in our first experiment. So that was that was wonderful and we we did some moderate lying to these children because we told them it was a programming course. We just said this course will teach you Scratch nothing else. However, secretly we had programming in the course but also code smells. So every week I explained the programming concept like a loop or a condition but also I said here's an example of you know this is very long maybe you could also split it and then it would be more readable and we even said to children that we did experiments in the university and where we measured that those small scripts are easier to understand and with that we could measure if it's possible to teach mess because the course h not only had videos but also quizzes So we could measure do the kids score better on the programming concepts than on the smells concepts or do they really understand the smells. Can we explain code smells? And the short answer is yes. Kids did significantly better on the smells questions 85 points on average out of 100 versus the programming concept 72 points out of 100. So it's even the case that the questions about code smells were somewhat easier to understand than questions about smells. And these were 7 to 11 year olds. So really young kids already can reason about the quality of source code is what we found here. So that's that's a promising story. I guess my not so very secret motive here of course is that these children those 10 year olds in eight years they'll be in my university classroom. So if I get them when they're young and I teach them about codeat smells then maybe in a decade my life will be easier because if I don't teach them then those eight-year-olds will say hey you know I tell them don't do code smells because it's bad and they're like yeah but we have doing this for eight years teach so why change now so this is my secret motivation that I want to teach about code smells while also learning programming so at this point we're about a year now in this story of programming for It's I am figuring out that this is maybe my new topic because I've now done four papers about different aspects of code smells and programming for kids. So it's not just this one off thing anymore. And at that point I think maybe it's time to look back. Maybe it's time to look at the water of programming I was in because because it was such an adventure that just happened. I didn't really have a strategy. Sometimes if you make a plan like I had in my PhD dissertation, you have a clear plan and you think about what is my vision and what is my research philosophy before you start. But it sort of just happened. So after a while I wanted to go back and understand what what is it I'm doing and I realized that I was making many many assumptions. So for example, one of the assumptions and maybe they occurred to you while I was speaking. One of the assumptions that I made is the domain is irrelevant. In the first study we did with the code smells, I didn't even think whether or not I would do a game and whether or not that would be the best representation. It was a non-decision. I just thought, oh, scratch games done. I didn't consider the impact of that on the experiment. Whereas usually if you're a researcher, you think about what is the impact of all the choices you make around your research design. for example where I said you know you need fresh children it's sort of a joke but it's also the case that if children know you very well that might change the results of your experiment and of course also the type of program you choose will influence the results of your experiment potentially but I didn't even think about it was just programming games kits done that was the first one the other one and I talked about that already a little bit is I assumed assumed software does something and this is why the result that only half of the Scratch programs have user interaction surprised me. I didn't really know how to fit that into my mental model of programming. And the third assumption I made is building is learning. So when we started the online course, I didn't think of other ways of teaching programming. I could have taught programming by having kids read programs or speak them aloud or deconstruct them. But immediately I thought if you just build source code, kids will learn how to build source code. And while this seems very logical, if you think of many other areas where you're training something, you often train weird things that you're never going to do. For example, if you're training for a marathon, you're not going to do a marathon three times a week. What you do is one slow long distance training and maybe one interval training and maybe even some weightlifting or biking or swimming, which is sort of weird because you're you're never going to do those things in a marathon. However, this is exactly the way we train programming. The only thing we do if we train programming is doing the exact thing that we're going to do later in life. So this was a deep assumption that also I didn't really know how to break. But at least I said to myself, let's try to break those assumptions. Let's take them, pick them apart, and see what happens if I let those assumptions go. For example, let's say the domain is relevant. So I asked many kids, what do you want to program? Instead of saying, I like games, you like games, let's all make games, I said, well, what do you want to do? what do you absolutely love? And they come up with the craziest things. So, one of the kids in my Saturday club, it's the weirdest things. He says, "I want to make a website for the local supermarket. This is what I want to do." So, he went there, he made photos with his mobile phone, put them on the website. Yes, it's nice because then people can know when the supermarket is open. So, he put the opening times there and the telephone number. And then even the cutest, he googles for the street name of the supermarket and then Google doesn't show his website and he's really disappointed. He's like, "Why don't they show my website? It's so much prettier than the real one." So, I got to also teach him something about Google and the internet. And this is the weirdest thing. What teacher ever can come up with a programming exercise that talks about the local supermarket? But this is something he was really enthusiastic about. So the the atmosphere of the classroom changed so much when I put the domain first and when I worked with the assumption that what they were building absolutely worked for them. So one of the things that we also did is Donald Duck. They have the Donald Duck magazine here in Norway. Is that a thing? Oh, that's so cool because I gave this talk to people in like Americans and they didn't really understand how Donald Duck is a thing still. But in the Netherlands and apparently also in Norway, you have this Donald Duck magazine that's still every week or every month and and people read it. In the Netherlands, we have 17 million people and 1 million have a subscription to this Donald Duck magazine. Everyone reads that. And the nice thing is that in this Donald Doug in the Doug universe, there's lots of different types of stories. You have love stories about Donald Duck and Daisy Doug, but you also have these adventure stories with Scrooge McDuck wants to find a treasure. So, it's a very rich universe that everyone knows. And this is what I brought into my classroom. So, you can see here this our classroom and here are all these Donald Duck magazines that I brought and I said to the kids, take your favorite story and recreate the Donald Duck story in Scratch. You can pick your favorite, just do it. And I have an example here of a story. Sadly, I'm sorry this story is in Dutch. However, I think probably if you're a Norwegian, you can maybe even read it. But the story is quite simple. Donald Duck comes into the office and then Scrooge McDuck says, "Donald, what do you have there? It looks like a once and then it's not Donald Duck because it's uh the witch lady that was pretending to be Donald Duck." And then Scrooge McDuck says, "Oh, Marika, this is the witch lady." Oh no. And then she says, I'm going to change you into a frog. And then from now on, you'll be known as Dbert Frog. And then he changes into a frog, which is it's a simple story. Nothing really happens. But it's it's very very viable to program in Scratch because people that have done Scratch know that the sprites can change into other sprites. So let me show you how this story can look like in Scratch. What are you? What do you have there? It's like a wand. Yes, indeed. I have something for you. You'll be a frog. And then it changes into a frog. So it's very very simple to program in Scratch because you can have those sprites change appearance. And you clearly still see the relationship between what's happening in Scratch and the story, even though of course it doesn't really look that nice. And the cool thing here is that kids explore these type of exercises in an entirely different way. So some kids were really excited about making it look more like the comic book. So they started drawing, which Scratch also allows. It has like a paint interface where you can change the background. other kids really started to explore the rest of the story because he's a frog now. Now what will happen? Will he remain a frog? Will he bathe in his money bin as a frog? So there were different angles that kids could take from this story and it was really interesting to see the different things that they did there. The second assumption of course that I had was that all programs have interaction. What happens if we let that go? What happens if we start creating programs that don't have interaction? For example, create artworks. So I ask kids again, what do you want to build? What is what about art? And then some kids say Pokemon is an art for a miss. Maybe that's true. But one of the things that we explored is Mondrean. Mandrean is a Dutch painter. Maybe you heard of him. was in the style and he makes these paintings that are really abstract with lines and squares and this is something that really really is viable as a metaphor for programming. So we I did that in a big classroom where the university had kids 70 kids in a in a programming competition and they wanted me to entertain them for an hour. What we did here is all the kids draw their own mandrean paintings. So here you see one that's maybe will remind you most of what they look like. And this was also very interesting. So the kids they think they will get a lecture about programming. They come into the classroom and I hand them a sheet of paper and pencils and pens and I say you have to make a mandrel painting. And these are 10 11 year old kids and there's already a boy that says this isn't programming. I will decide that sir please sit down and make a painting for sake. So they these are but we are doing this. We are telling kids what is programming and what isn't programming. The cool thing is, so I have them draw these paintings and then the next exercise is they have to compare their painting to the their neighbor's painting and then they can reason about abstraction because you have blue and I have yellow that means if we're going to create color in the painting at least color needs to be a variable because we have different colors and if one has lines like this and the other one has lines like this then the direction of the lines is going to be a parameter into the program as well. So comparing these paintings is a really nice way to talk about abstraction before you talk about abstraction in source code. And later we you will see that in the scratch program we created our own blocks with parameters and then I had two pieces of source code next to each other that will would later become the function. Look at these two pieces of programming. What is the difference? Because the difference will become a parameter of the program. And then of course I like I play with them a little bit. to see how how important it was that you practiced comparing things because you would need that skill in programming and they're like, "Oh, oh, maybe she knows what she's doing." So, here's a program and you see here the purple blocks are blocks that we created ourselves. So, they're functions that you can use in the program to generate many different Mondre paintings. And then this is how it looks like. So it creates a line and then it creates another line and then it creates a blue block of a certain size and then with this program all the kids were encouraged to recreate their own paintings and then some weren't possible because some didn't have the the proper constructions yet. One of the dads made victory boogie woogie one of the few paintings by Mandrean that doesn't use this lines but they use diagonals. So yeah that is impossible. It's interesting to see what the boundaries are as well. So again, it's a very very interesting way of teaching programming that's different from what we usually do. And then there was this third assumption I still had left that was very, as I said before, very deep. Building is learning. If we want to teach kids programming, we just have to do programming with them. It's really how most people teach programming. It's even not even university classroom teaching but also teaching as in here at this conference. Most of the people that do workshops or that do talks do programming and they show this is how you use our library practicing what people would do if they use the library rather than maybe doing weird exercises like the Montreans that would benefit skills. So what is the reverse of building as learning? I wish I had this story where I was sitting under an apple tree in Cambridge and then tada Eureka. But that is not really how it happened. It was more a process where I I was in Cambridge. So that was a good start. I did a sabbatical there over the summer last year while I was thinking about this but it was really a slow process where I was thinking about this every day and what could we do the domain is is relevant and also no interaction is needed. What does this remind me of? It's like writing because if you think of writing, the domain of writing is really very relevant. We have all these different professions. All these people are arguably writers. They're writing as their profession. But it really matters if you're a journalist or a poet. what you do with writing really influences what your job is and how you look at yourself and probably also how you look at all the other professions. So in writing immediately you feel that if you're a writer then what you do with your writing will influence you and here journalists there's a container but that you have financial journalists and political journalists and economic journalists and they all need not only writing skills but also skills about the domain. So in writing the domain is absolutely number one almost. And of course in writing you also don't really need interaction because I can write a book now and you can read it in maybe 3,000 years. So in a book by definition there's no interaction. You just write it and it is what it is and the interpretation has to come from me. So programming is like writing is sort of the conclusion that I that I arrived at because if you think about it ultimately what programming is is it takes an idea a very very high level idea like an app that tracks compliments. This is something what I want if someone says something nice I'll just say can you say that again and I'll record and I'll play it back later. It's like Twitter but only the good parts. You take that idea and what you do is you transform that idea into letters and sentences. That's ultimately what programming is an idea, a very high level idea and it turns into letters and sentences. And maybe you use some things in the in the meantime like a UML diagram or a user story. There are steps in between but the idea is from idea to letters. And this is what writing is too. You have an idea about a crazy story that you might want to write like a frog murders for un diplomats because why not? You take that idea and you transform it into letters and sentences. That's ultimately what writing is. And like with programming, some people use things in the middle. Some people use, for example, they write a table of contents before they even start writing the story or they write character sheets where they say this is what the character is going to do even though it doesn't appear in the story just for them to get a feel for what's in there. So ultimately it's very very very much the same. And it's not just that this is like handwaving. If you look at what people have written about what programming is and what writing is, you see concepts that are really familiar. So for example, here you see the definition what programming is by PRA. It's a book from the 80s about how to teach programming. These are the steps that people take when they're programming. So defining the program, the problem, designing the solution, writing the source code, compiling it, running it, testing it, and maintaining it. Those are the traditional steps even though it might be more cyclic in reality. These are the steps that people usually take if they're programming. And then if you look at writing, writing traditionally is seen as gathering information, selecting the information, structuring it, translating your ideas into letters or words and sentences and then styling, formatting, and reflecting on your task. And like with programming here, it's usually a cycle where you're secretly also reflecting while you're writing. But these are the steps and if they're in a line, it's nicely to put them next to each other. So here again, you have the steps of programming and writing next to each other. And you see that there are a few cases that are really, really similar. Gathering information and defining your problem. It it's the same thing. Both are understanding the context of your problem, the story or the app. And there are some that are somewhat related. So in writing, you have selecting information and structuring information which in programming is one thing designing and on the other hand our reflecting on source code is a bit more structured. We have testing and maintaining. That's of course because software is more a living system. But still there it's clear to see that there are relationships between the different steps. What's also very interesting is that writing is different also in some cases because writing has three steps for the real writing. Translating your ideas, stylizing and formatting. Whereas in writing we in source code there's just a step writing the source code. And this comparison leads to interesting definitions because why does writing have stylizing? What if you have style in writing? For example, here is an example of this is a hesitant style. If you read this piece of writing, you're like this person doesn't know what's going on. I rather think that it was the same character I met. But where? In front of a church, in front of a charal house, in front of a dust bin. It expresses hesitance and confusion in the way it uses words. The information is still you could have also have said, I don't know where I met this person before. But you use style to emphasize confusion. What is this in programming? Do we have different styles of expressing lines of code to express the feeling that we have with it? So, of course, you can think of programming style like good style, like we're back to the code smells. This isn't good programming style because all the variables have short letters, short names, and it doesn't have comments. So, you could say this is better style where it has documentation and clear variable names. This is definitely an aspect of programming style, but as you see, it's not as strong as the style in writing. Maybe we want something like a hesitant style in programming as well. Maybe I want to be able to express I don't really know this. And it's sort of funny, but it's also why not why couldn't we explore how to use style in source code? Why does it have to be precise? A compiler can deal with different forms, at least with some of them. There are lots of programming language that allow you to do one thing in different ways. So why couldn't I express hesitance in a line of code? It would be nice if I come back to the source code 10 years later. I was like, oh yeah, I wasn't sure about that. And maybe this would lead to a different execution model where instead of one variable you get a list around dist distribution around that variable that's calculated throughout the program. Our compilers could do that. So thinking about how style reflects in writing and how that could also occur in programming at least for me is a super fun exercise. And the same goes about formatting. So in writing of course you can take your writing your letters and format them in ways that extend or enrich the meaning of your writing. So this is called a diamond poem and here it is shaped like a diamond and you have nice pictures with it. It's sort of different and it helps you understand. If you don't even know what's going on, if you just see the pictures and you see the shape, then things happen in your brain. Formatting enriches what's going on. And this is something that could exist in programming as well, although sadly not everyone agrees with me. Code style essentially is a solved problem. And what Ken Arnold argues in this book is that formatting should be done should be enforced by the language. This is what he's saying. Programmer should have less freedom. You you shouldn't care about formatting. Either the compiler should do it for you just fixing it when it's there or a Python style where formatting is just enforced by the language and it only compiles if you do it the proper way or you could have something like a llinter that fixes it for you. I understand this vision, but I don't think just formatting the source code, if we're talking tabs and spaces, is covering the entire scope of what we can do with formatting. For example, here you have a piece of source code formatted in in a way. And you could say that this program is the same program formatted in a different way where you put the assignments closer to the variable def declarations so that it's easier to understand what variables are used in what assignment. This is not something that a compiler could enforce or a llinter could fix because you're making clear decisions about where you want to use the declaration such that they are closer to where you're going to use them. In a sense, the second version is more taking the reader through the story. Like here's a character, here's a character, they meet, here's another character, here's another character, and they meet. In a book, it would rarely be the case that the first three pages are all the actors in the entire book, and then all the stories happen. That would be super boring. So I think there's despite what Arnold is saying, there's still a lot of room to think about how to format programs even though we're not talking about tabs and spaces. So why is this interesting? Maybe you're wondering this. Why what can we learn from these ideas comparing two things? Because I mean you can compare two things there. There's not always something in it. I could say I am an object and this is an object. It's not necessarily something really interesting in comparing me to I don't even know how this thing is called. So comparing is fun but there has to be something in it. So one of the things that is interesting in a very detailed level is it's not only that we can learn from writing it's also that writing can maybe learn from programming because we have very cool things like syntax highlighting. We do some auto formatting as probably writers would call it. We take a piece of source code and we call outer the words to help us understand what's going on. And there's quite some research actually that shows that syntax highlighting helps understandability. It makes you read source code quicker. This is something we could do for writing. Maybe it helps especially novice readers or readers in a different language if you would call our words according to what role they play in the sentence. I'm sure that I would be more able to read Norwegian if the verbs would be colored because you immediately see the structure and Norwegian is close enough to Dutch so that I could also pick up some words. So this is clearly an area where writing could learn from programming and then of course this like this is a PhD dissertation right there because how much detail do you need in the words and do you need to have this forever or is it is there a learning effect? It's really interesting to do this transformations but this is somewhat at a very detailed level. There's a higher level of thinking that matters here as well. For example, program writing has this wonderful idea, this distinction between plotters and pancers. So there are people that identify themselves as writers plotters and that means you think very loud. I have a plan. I'm a plotter. Thinking, thinking, thinking. The first thing you do is think. And then you just write your story. The main activity is in the thinking up front and then you write your story. Whereas if you're pancer, I'm a pancer. I know this. The first step is just writing. You're not going to think. You just let the story unfold itself. You start with writing. And then the heavy thinking, the heavy lifting happens when you're rewriting the story. And these are two different schools. And it's sort of understood that it's not so much a choice as it's more a thing you are. And this is very very interesting to compare with programming because how you think about a field really shapes what you do in the detailed activity. So compare the plotting and pencing to engineering. Engineering, if you're making a bridge, plotting is the way to go. You need to think about the bridge. You need to write all the designs, all the steps, and all the measurements, and then you have a bridge. This works, but you can't pence your way out of a bridge. You can't think, "Oh, I have this idea of a bridge. I'll just build half this bridge and then I see if it's really nice and then if it's not pretty I'll just make it different with some wood and some concrete and it will be fine. So engineering and plotting is the same metaphor but then we use this metaphor in programming all the time. This architecture metaphor is everywhere. software architecture and scaffolding and engineering maybe we're catering more for plotters than for panthers whereas if you would see programming as writing then so I I'm this metaphor for me really helps because sometimes I'm plotting programming if I'm making something for a customer but sometimes you're pancing programming you don't really know what's going on you just want to understand the problem by programming it. Programming for understanding and this is just something that doesn't fit the engineering metaphor. And that's interesting. So there's nothing wrong with the engineering metaphor. However, it's you should realize that the metaphor shapes your thinking and it only represents potentially part of what programming is. And another reason why this is really interesting and this is sort of the the core of my story is we could learn from writing education on how to teach programming because lots of programming education like my stuff at the community center isn't really designed. They're just volunteers and often parents that say oh I will teach some kids programming but they don't know education and especially they don't know writing education. So what they do is what I did as well. Oh, let's build games and it'll be it'll be great and everyone will have fun. But there are some lessons we can learn from writing that could very much support programming education. For example, in writing education, there's this concept called observational learning. And the way this works is a teacher explains how they write a story while they're doing it. So they say when I create a story the first thing I do is make a plan and then they write the plan on the blackboard. They explain their thinking of how they make a story and they take it through their thinking and sometimes they make a mistake and they backtrack and they try again. And in this way, the idea what's going on in their brain is conveyed to kids in the classroom because what's often the case if you don't use observational learning is teachers just say, "Oh, let's write a story." And then it's bad. But the kids don't know what the process is, so they can't really get it. And this is something that could work in programming as well. Rather than immediately have kids write a program, what you do is you create a program while explaining while vocalizing your thinking. And then you make the program and kids move along with you without doing anything. They're just observing. And maybe now you're thinking this is something I do. We call this live programming. And something that many people do is in conferences rather in conferences than in classrooms. In a presentation like this, they open their IDE and they show what they're what they're doing called live programming. So it's something that some people have already picked up but they don't really make the connection between the educational background of all the lessons that other people have already learned from observational learning. So life programming seems to be a really good idea and it would be nice if this would be employed in classrooms more and maybe also with younger kids. And I would say again there's another PhD dissertation in there like how long does it need to take? Do you need to alternate it with exercises in which kids write their own source code and how often? These are all very interesting ideas that I will explore in the future. Another thing you can learn from writing education for programming education is course integration. So there's quite some research that shows that if you integrate writing education with science education for example that kids learn both subjects better. So the imagine two control groups one of the groups get an hour of science and an hour of writing unrelated and the other group gets two hours of integrated lessons where for example a teacher talks about a volcano and then the kids have to write something about the volcano. So they do writing in a context that matters to them and this means they do better on both subjects and this is something that is very very viable for programming as well. Why couldn't we combine programming and writing? Because there are so many things that you have to explain twice otherwise. You can say, "Hey, syntax. This is a sentence in Dutch that is a real sentence. It means something. Here's a line of scratch that works. It does something. Is the same thing. And if you change the order of these two words, it loses its meaning. If you change these two blocks, it doesn't mean anything anymore." So there are concepts in programming and writing that you could teach together. And this of course very much relates to the Donald Duck lesson I talked about earlier where kids create a story in Scratch and you could use that as a basis for a lesson about storytelling because afterwards you could say what type of story was this? Was this a love story or an adventure? And this is a typical exercise that eight nine year olds would do in a classroom. Think about what is a story and it doesn't have to be a story on a paper. It can also be a story in an animation. Why not? We just did an experiment where we did this for two months. For two months, we thought 35 kids integrated programming and language lessons and we measured their understandability of programming and their enjoyment of programming. And it it seems indeed that they are starting to have more fun in programming and in writing. We still have to check if their grades will also improve but that takes some more time. But the most most interesting about this experiment that we tried is at the end of these two months where we teach taught kids programming and writing lessons integrated. We asked those kids the question, what is programming? And we got the most amazing answers. Some kids said it's like a puppet theater but on the computer. It's so cool and it expresses their their power, the power they feel over the system that they can create everything that's going to happen. You create a story and then you share it with the world. I love this too where we're changing this idea of programming is something you do for yourself on your computer into I create something and everyone can see it. And this is of course not just about our lessons, but also about Scratch, that the interface enables you to share everything. And this is like maybe one of my favorite ones, teaching the computer to do what you want. So this this person already is abstracting from what programming is and then it's stories, but it's everything. And it's really very interesting if you compare these answers to kids where we had the more gamebased curriculum where we only read games. So they say programming is making games and just as with the engineering metaphor there's nothing wrong with programming games but we have to be aware that if we are projecting on kids programming is games this is what they will think and that that does shape our culture. So I think it's very good if we have all these diverse type of lessons that it's not just games, it's also writing, it's also science, programming. With programming you could do everything. That's more or less what I wanted to share with you. Let me summarize my entire talk in about one minute because I know it's early and I talk really quick and some people came in late. So here's your second shot to get the gist of this talk. If we talk about programming and especially if we talk about teaching program to children, we have to really think about what is programming and it's difficult because we are programming all the time. So we all have have our own little bubble of what programming is but especially if you're teaching you have to be aware that you're swimming in water and there might be some air up there. That's also nice. Programming is like writing because it's an highlevel idea that you translate into letters and sentences. And you can think, huh, what does that matter? But the metaphor we use for programming really matters. And the prevailing metaphor we have now, the engineering metaphor might not be suitable for everyone because if you look at writing, there's this difference between plotters and pensers. And the engineering metaphor only fits the plotters. What I'm going to explore in my research in the next I don't know how long I'll still be at the university in the next few years at least is the idea that we can learn from writing research to improve programming education for example by focusing not on having kids program from the start but focusing on showing the thinking of the teacher before they start exercising and also the integration of programming lessons and language lessons because things like syntax text things like refle reflecting on quality things like peer review are all things we can totally take away from writing research that's the end I'm Felina if you want to read more about this my blog is felina.com people always ask me how you make this slides they're made with good notes and an Apple pencil apple pencil is the best device in the history of mankind I love it and special thanks to smart people that helped me design this room for questions five minutes. Any questions? I know it's early. How old were these kids? Oh, that's a good question. The 35 kids were between eight and 10 year olds. So, really young. And they were still, for example, learning syntax in the context of Dutch lessons. And this is why we selected that age group because we could nicely combine learning about what is a verb and what is a noun and learning what type of blocks are there within Scratch. We hypothesize that would be the best age because then you can learn those concepts together. No more questions. Okay, let's go for coffee then.