What to call flow of control with 3rd - 6th graders?
« Computer Science Education
- Login to post comments
susan evans
Member
May 18, 2011
I was thinking today about the way in which I talk about flow of control with my students. I usually say things like: "it" goes here, or "it" does not go here, or "it" only goes here if this is true. I have been trying to come up with better ways to say "it" which would have more meaning to younger students. Does anyone have any ideas? Single stepping in Scratch helps but I would love any suggestions of other words to use instead of "it". Thanks for any/all contributions!
The instruction for computer to do the action goes here. Then the action will be performed and you will see the result such as the Sractch Cat moving.
I normally refer to the sprite that the script is controlling e.g. "if we hit the right arrow key then Scratch Cat will move to the right". In my opinion, it depends on the age group and extent of exposure/familiarity of the student to related computing knowledge. If the person is much much younger, or if s/he is a beginner, then that is exactly what I would say. It preserves the programming concept and yet does not overload the beginner with too much "unnecessary" info.
I create and step through projects with beginners on my Scratch resource site - you're most welcome to see how I talk about about "it" there: FunWithScratch.org
I just realized that the subject of your post and the description you gave are slightly different. Are you asking for a definition of flow of control, or how to talk about it?
Using the analogy of recepies and cooks, the "CPU", or even "the computer", follows the instructions in the script and every time it encounters a conditional statement, it has to decide which set of instructions to follow next based on the validity of the condition.
I can live with that. The CPU is the one that actually "goes" here or there by changing the value of its program counter --different architectures use different schemes, but the idea is the same. In a x86-based architecture, for example, a conditional statement ends up as a series of instructions for evaluating the condition, a comparison instruction (CMP), the selection of the right course of action using one of the many jump-on-condition instructions available (like, JNE for "jump if not equal") and possibly using an unconditional jump (JMP) for implementing the "Else" part of the conditional (anyone remembers assembly language?).
I once had a professor that used to say "and the program goes here if the condition is True." This was very peculiar to me as programs, like recepies, are passive elements (Ok, putting self-modifying programs aside for the moment) and as such "they" do not do anything.
One funny thing that always comes up, is that some students would end-up blaming the CPU when something goes wrong in their programs not realizing that "they" told "it" to do exactly "that."