2 Sequence
A,B,C. It’s easy as 1,2,3. As simple as do-re-mi.
The Jackson 5
A computer program is a sequence of instructions for a computer to execute. Identifying the proper sequence of events is a vital skill. That’s the main aim of this section - breaking things down into sequences. The secondary aim will be to practice iteration, by experimenting with sequences of things we’ll initially get things wrong, but by iterating each time we will get closer to a good solution.
2.1 Examining and building a sequence of instructions
Let’s get straight to it and break down a sequence.
- In pairs work out who doesn’t mind being bossed and who doesn’t mind being bossy 1
- Bossed partner: Close your eyes! (or at least look away from the screen)
- Bossy partner: Watch one of the videos 2
- Bossy partner: describe (using spoken words only) how to perform the sequence of moves in the video. Bossed partner: Do only what the bossy partner tells you, are there any points where you need them to be clearer? If they aren’t making sense - say so.
- Write down the steps as you go. Work from the steps.
- In your design journal:
- Reflect on what was easy/difficult about being bossy
- Reflect on what was easy/difficult about being bossed
- What was difficult about watching?
The process above may have revealed a few points. The most apparent is that in order to be understood it is vital to be explicit about the action. Another is that the receiver of instruction (here the bossed partner) is not (often) able to ‘just do what you meant’ and get it right. The whole process probably took a few goes at least while you worked it out, so iteration is important. The list of instructions you created was a prototype program for a dance! This form of program, not real code - but a good description of the important parts is called pseudocode. The first draft of a real program will often be pseudocode.
2.2 Building a sequence with constraints
Computer languages don’t have a command for each possible action. They instead have very restricted sets of key commands that must be chained and used creatively to make larger effects. The commands they do have are often quite limited and do very specific tasks.
This is a deliberate design feature. Flexibility and power comes from these small units, chained together in novel sequences.
In this section we’ll examine using small units in different sequences.
- Start a new Scratch project
- Using only the below ten blocks, make something that interests you
go toglidesayshowhideset sizeplay soundwaitwhen this sprite clickedrepeat
- Share your creation in the 10 Blocks Studio http://scratch.mit.edu/studios/475480
- In your critique groups or your design journal, discuss the following:
- What was difficult about being able to use 10 blocks?
- What was easy about only being able to use 10 blocks?
- How did the constraint make you think of things differently?
2.3 Fixing some bugs
Let’s examine some broken sequences and try to fix them. In this section the aim will be to explore the central sequence, and practice iterative testing and de-bugging. This is your first opportunity to try out the major parts of the development cycle.
- Do the five debugging challenges described on this debugging sheet
- Discuss your testing and debugging practices with a partner. Make note of the similarities and differences in your strategies.
In this section we’ve looked at the importance of sequence. Breaking a problem down in to small parts is a key step to solving it. Programs are built from a sequence of small units executed in a particular order. Applying and replying combinations of commands, testing them and repeating until the combination works is the main development loop of programming.