So, rather than talk generally about the challenges students have with abstraction which could be bigger topic, I'm just really going particularly talk about the challenges students have with methods and parameters, because that's a form of abstraction that we are looking at. Remember, we have general and language-specific things. We're going to look mostly at general, although I will point out a couple of places where actually Snap and mini Block-based languages make some of the specifics to them, make it easier for doing abstractions and parameters. All right. One of the biggest challenges students have is understanding the difference between, when I'm calling the method that I've created or the Block that I've created, and where I'm defining. Whether it should be done when I want that method to be called. So, on the left, we have the definition, that when you call paintPicture, you want to have these four instructions happen; fillSky, drawSun, drawGrass, drawFlower. On the right, we've got the example where somewhere in your program, this one was really really simple, you would call that method. Now, this is actually one of those places where Snap makes this a little bit easier, because when you just say, "Make a new Block", it pops up this Block editor, and that's always where you're going to be putting your definition of that Block that you are creating. So, this tightly ties into just understanding how is control actually flowing? What instruction gets done next, and next, and next when we are talking about calling a Block that you have defined? So, let's start with the code on the left. I made it a little bit more complicated. So, we've got say First, if this is under when the green flag is clicked, okay? That would be the first instruction that happens, and then of course, as usual, you will go on to the next instruction, fillSky. Now normally, an instruction we don't think of like what the code is underneath it. There is code behind the instruction say First, but we don't know what it is and we can't access it. FillSky is a Block that we created. So, when we're debugging, for example, we may want to go in and access that code or trace what's going on in that code. So, what actually happens next is this Block of code, the script, actually jumps out over to this Block over here where we defined fillSky, and then we start doing the instructions there. So, we would do set pen color to turquoise, pen down, fill, say second for two seconds, and then what happens next? Well, this is the part that sometimes gets students. It's a little tricky we're actually now we're done or done finishing executing that filSky Block that we have, and so we actually go back to the script or method that we are in, and we go down and we execute this instruction. I will just take this time to point out that, yeah, we're using some words interchangeably when we start talking about abstraction. We've talked about method. We've talked about procedure. We've talked about functions, and now I'm using the word script, which is something that is used more commonly in Snap and Scratch. Although there are differences between them all, for the purposes of K-12 education, generally we don't need to worry about the differences. All right. Well, we're talking about names. Let's bring up another really challenging name thing. We've been using the term variable for a long time. It's a value or placeholder. Remember the envelopes, we can stick a value inside it, it's a place holder for something. But now we've introduced this new term parameter, right? Let's go back. Well, those don't have any parameters, we'll go forward. Parameters are the values that we might send to an instruction that control how it acts, and we are used to having parameters, like the say Block, and we say, say hello for two seconds, hello and two seconds are our parameters, okay? This is a really hard thing to say because we can also call those things variables. It turns out that parameters is a subset of variables, but only kind of. Here comes the complex explanation, and then I'll give you a nice summary at the end. Okay. Let's look at this method. So, this is the definition of the drawFlower method or Block. These x and y at the top, those are our parameters, right? What x and y coordinates do you want to draw the flower act? That's makes a lot of sense when we were creating the drawFlower method. We had to indicate what parameters we wanted to have that we'd be using to control the instruction in the drawFlower method. Then, we use those parameters someplace. By the way, if you don't ever use them, then you shouldn't be sending them. Down here in the goto instruction, we use those parameters x and y, and we could say, yeah go to x and we give it the parameter x, and go to y and we give it the parameter y, because they are both interesting, they're both parameters from drawFlower, but they're also now going to be parameters to the goto method. That probably got confusing. But you can use the word parameter for discussing any of those four things. However, you can also call these guys down here variables, because they are variables in our use in this code. I mean, we could add one to them. We can subtract one to them. We could do lots of things with them, okay? They are variables and they are essentially envelopes that we can stick values, and we can change the values in x and y. So, in that case, we could call these variables and we'd say, "Yeah, go to xy where you give it the variable x and the variable y as the parameters." See, I just use variable and parameter together. It's true. Let's talk about where we would maybe call the drawFlower method. So, here's our code that we were executing to paint the picture, and we were calling the drawFlower method. Here, we tell it what x and y coordinate we want, 145 and 130. I just made those up. We would call those parameters. We can't call them variables, right? No, can't call them variables because they're not variables. They're not an envelope. They don't have any label on them that we can put some new value in. So, they are in fact, parameters, but they're not variables. They're parameters because of the location that they sit in, right? They sit in the instruction after the name of the instruction, and we use them to then send values that would make a difference in how the drawFlower method works. So, they're parameters but they're not variables. So, despite the fact that I just showed you an example where a parameter wasn't really a variable, this is, generally, a good way to think about it in terms of what possible names can you use for something that you see encoded in this things you have. Now, I would say that there are many variables and sometimes those variables can't be parameters, right? They can be values that we send to a method that we use to change how that method happens, and how that Block happens. One way to think of this is with the following: I think it's an analogy that there's a big set of humans and some of those humans are teachers. There's a big set of possible variables out there. Some of those variables may act as parameters. Then, the only one key thing you have to remember is that sometimes when you're actually calling a method, and this was only possible when you're calling a method, that those parameters you might send in it might be just static numbers or values that you would send. Like set pen size to eight, right? That's another one over there on the left. That eight would be called a parameter to the method or the Block set pen size to. Yeah, names are important. It's important to have quality names that we can be clear about things on, but you can often use variable and parameter interchangeably, and we tend to use the word parameter based around either the call or the definition of a particular Block or method. That was probably a little confusing. You know what? It's so interesting that we don't really discuss that much. It doesn't seem to come up much when we're really teaching program. We just throw out so many words I think that students are usually really overwhelmed. All right. Let's talk about how parameters actually work, okay? To go back to this, we're going to imagine what happens when we call the drawFlower method. Now, down the bottom left, and it goes over and starts executing the definition code for drawFlower. So, we call drawFlower, we pass in two parameters, 145 and 130. See, I use the word parameter. What's actually going to happen is it's literally going to take a copy of that number 145 and put it up there, and I already overrode it. Let's look at it, it was x and then y, it's going to put 145 into x, and put 130 into y. What's another way to visualize it? Well, it's as if these two instructions were added at the top of the code that says "Take that 145 and set the value x to that, and take the value 130 and set the value y to that." So, now you've got those variables available to you, x and y, that have preset values by the purpose of, or by the process of passing those in as parameters. So, even though that code you don't ever write that, that's done automatically for you by the computer. Then, really as students start creating their own code, their biggest challenge is actually going to be, what parameters do I need to make or one to make? When you're having students create their own creative code, and what they want to do, this may not come up as much, and it often doesn't come up as much until you think about, well, if I'm going to use my code in a lot of different concepts, so I want to be able to reuse it, how would I make them? But just to give you an idea. When we were drawing our sun, there was some hard, what we call them hard-coded value, some things that were not controlled by variables or parameters. Like setting the pen size to 60, so that when we drew the sun, we could maybe have the rays be different levels of thickness. Actually, it's not a ray. Oh, I don't know. But you could imagine setting the pen size to something, or that would actually control how big the sun is. Boy, we should change that name. The name here, this is the definition of the drawSunRay method or block. Down here at the bottom, it looks like we're making all of our sun rays be 50 steps long. Well, maybe you want to have some be longer or shorter. You could add a fourth parameter to x, y, and angle and indicate the length that you want that ray will be, and then instead of that 50 you would use the variable or parameter rayLength. The one thing that Block- based languages really helped with, and as far as I know, all of the Block based-languages have this benefit, is that they make it very obvious to you what order your parameter should be in. So, we just looked at drawSunRay which had three number of parameters; 70, 130, and 290. In a non Block-based languages, it can be hard to keep track of which one is supposed to go first. Is it x, y then angle? Is it angle then x, y? Is it y, x and angle? It's easy to get those confused. Because of the Block format, it actually shows you the name of each of the parameters that you're going to pass, both when you call it. Then also, in this definition of where you're going to define it. They make it really clear what each of the parameters should be. So, as long as you give those perimeters meaningful names, like x, y, and angle, then it shouldn't be too hard.
