So, like we did before, we're going to look at general common problems people have in two senses. First, what general problems across many programming languages do people have with repeats, or as we're going to learn, loops. Then, what are some of the language-specific ones that belonged to snap? In this case, we're actually going to find out there's language benefits first. So, let's start with general. The key thing that students struggle with is understanding what is being repeated, okay? This is a little hard in a language where you have a visible output, like a sprite moving. It's even harder if you don't have that, if you're mostly calculating numbers, and you're not able to see the results of every instruction being executed. But specifically, when we teach looping, we really try to focus students on recognizing there's three spots that with regard to any one loop, things can go. It can either go before the loop, and it happens only one time essentially in the code. It can go in the loop where it happens in the repeated number of times, or it can go after the loop where it happens only one time. So, the number of times I say to students is that happening one time or many times. One time or many times, and that is supposed to indicate, again, is in the loop or not in the loop? I'm sorry, not in the loop as one time, in the loop is many times, and then sometimes, you need to be sure they know if it's before or after. So, a really good tip is to have students identify which actions are repeated and how many times. How can you do that? Well, this actually works better in non-sprite based languages, but you can make it work in sprite-based languages too. So, ask students to make a table to just also gives them this idea that we can have this regular notation of what's going on. As you play video, you're going to have to sit there and stop it very quickly or play it real slow-mo. Have them write down an action they see happening, and then the next action they see happening, and the next action they see happening, and then as soon as they see an action happened that they already wrote down, it's a possibility, it's not a guarantee actually. It's just a possibility that's going to repeat. So, you should have them go up and look at that, and then if the next action is the one right below it, that's probably going to be a repeat, but we have to actually make sure. But the point being, you can encourage them to keep tally of how many times things are repeated, a given action is repeated. Let's talk about some language-specific things. Again, what is really great about snap, and mini-block based languages, is that they really bring out this clear structure of a repeat. That a repeat isn't a single action, it's an action that controls another group of actions. That is so hard for us to do on without block-based languages. So even if I was going to be teaching first language of Python or Java, I would introduce this structure just so students get to see it. The other thing that they did really well is they didn't call this a loop, which is the common computing term for repeating instructions, we say looping. We have different kinds of loops, we'll learn more about those. These are called what we call counted loops. Often talked about for loops, you might have heard. See, all those names don't take nearly as much sense as repeat. So, that's something snap does really well. Students tend to have no trouble getting into the repeat idea. The other thing that goes along with helping them really get into it is that again, every single action whether it's before the loop after loop, or in the loop, or repeat is visible, and so they can count that and match that up. That's really helpful in snap. So, as you are working with kids and helping them try to debug things around repeating, one of the things that can be a real challenge is, especially maybe they're working on a program of their own design, and they went to repeat something but it's really hard to see because like move 10 steps, tell them that even though you can change it back later, why don't you make it the number of steps bigger for a while so it's easier to see. Then you debug it till it's doing the right shape, or whatever that you want, and then you can change those steps back down to make it go in a smaller space. Another tip that I'd really encourage you all to just grab a copy of this slide, and you do it with your students, that I would like you to point out the differences in what can seem to students like identical code. So, you've not seen this programs before. Please take a minute and read them. So, hopefully, what you see is that at least nominally, all of each of these programs causes a sprite to turn 180 degrees. The first one, we're using our hand. We pointed out before that's good. Turn 180 degrees. Okay, good. The second one, we're going to repeat an instruction 10 times. Turn 18 degrees, turn 18 degrees, turn 18 degrees, turn 18 degrees, ten times. I can't be very accurate with my hand but that's good, but it's going to be 180. Then, the last one is repeat 10 times, turn 18 degrees, wait one second. Turn 18 degrees, wait one second. Turn 18 degrees, wait one second. All right. So, that's going to continue 10 times. They will all after the program is over, the sprite will be in the exact same location after doing any one of those programs. So, students see this and they think they're like, "Well, this is just dumb or why can't I do it one way and not the other way, et cetera?" This is a great time to reinforce with students that computers aren't perfect, they actually are literally reading the instruction that you give them, and it takes the computer time to read your instruction and go, "Oh, what is it they want me to do?" Then, they actually do it. So, turning 180 degrees, they just read one instruction, and so they can do that fast. The next one, I have to read the repeat, turn 18 degrees. Actually, go back up and repeat, turn 18 degrees, and so with that's one what it's going to look a little jerkier and slower. Then, the final one, by putting that weight, we actually can just really make it differentiate and look very different and easier to count the repetitions. But there can be different codes that normally have the same final outcome, they might not look exactly the same getting there. Definitely, just that last example pointed out, if students are having trouble matching up of actions and a repeat with a video that they're watching, use waits to make individual actions easier to count and observe.
