Flow Control In Primary Programming: In primary programming, do learners need to understand the flow of control of their program?
The National Curriculum in England KS1 and KS2 Computing programmes of study doesn’t mention the need to teach pupils the difference between programs where there’s a single script that runs one command after another as opposed to programs with multiple scripts all running at the same time.
Nor does it mention teaching about coordinating action across such scripts, but block based visual programming tools such as Scratch include commands that encourage learners to implement these features.
In computer science ‘speak’, in a block based language such as Scratch, we might call these running blocks of code scripts; we might call scripts running at the same time as ‘concurrent‘ or ‘running in parallel‘; we might call coordinating the action across scripts of code as managing ‘dependency‘ or ‘synchronising‘ activity.
In this article, we’ll use the terms ‘concurrency‘ for scripts running all at once and ‘with coordination‘ for managing dependency.
Teaching Concurrency and Coordination Programming with ScratchJr
If we’re teaching programming using simple programmable toys, such as Bee-Bots, there’s just one script of code. Nothing can run in parallel on the single device, there’s nothing to coordinate, no coordination.
When we look at ScratchJr, concurrency can be seen in several ways. The most obvious is probably when a second character is added, and each character is just ‘doing its own thing’, each perhaps started by the ‘on green flag‘ trigger command.
Time can be used to try and coordinate action, but this is tricky as there’s no specific way to control how long a command takes to run. Broadcast using coloured envelopes, the ‘send message‘ command, clearly supports managing coordination across scripts.
Further scripts can be created by using the ontouch or bump trigger. In recent research on the use of ScratchJr, using the send and receive message and on bump triggers came in the bottom five of the least popular commands used in over 7.5 million projects (see Programming with ScratchJr: a review of the first year of user analytics), but no report was made on the average number of characters used, nor how often multiple scripts were coded for each character.
But we suspect that many young children create programs with more than one character each ‘doing its own thing‘, so they may be writing concurrent programs.
Teaching Concurrency and Coordination Programming with Scratch
In Scratch, multiple sprites are common. Recent research showed the average number of sprites per project was 5.6, with an average of 17 scripts per project.
Broadcast was used in only 30% of projects and ‘broadcast with wait‘ only 4% (see How Kids Code and How We Know: An Exploratory Study on the Scratch Repository).
How many projects used wait to coordinate across sprites wasn’t reported.
It seems that primary pupils are writing concurrent code, and many may be expected to create programs that require coordination across sprites.
Scratch was recently reported by The Royal Society (see After the reboot: computing education in UK schools) as being the most popular primary programming language used in England.
Therefore despite the English programme of study not requiring us to teach about concurrency and coordination in primary school, the products (Scratch) we’re using to teach programming have such features within them and many learners are using them.
The next question is, should we explicitly guide learners on the use of such features or just let them use them and hope they don’t develop misunderstandings or bad coding habits?
Research from a team in Israel found that concurrency and coordination were two of the hardest concepts for KS3 learners to understand in Scratch and recommended careful teaching to help overcome this (see Learning computer science concepts with Scratch).
Teachers in English schools, anecdotally, report that learners find these two ideas very hard to understand too.
In the ScratchMaths resources, broadcast is taught using an unplugged activity where children call out the lines of ‘The Grand Old Duke of York‘, responding to hearing the previous line in the familiar nursery rhyme.
How Should We Teach and Guide Use of Concurrency and Coordination in Programming?
Children understand that they can do more than one thing at once – they can sing at the same time as they jump, at the same time as they wave their arms about.
- But do we draw their attention to this idea?
- Do we give ‘doing more than thing at once‘ a name?
- What vocabulary do we use to talk about coordination?
- Do we have objectives to meet for these concepts, and how do we assess outcomes?
Learners seem to understand the idea of coordination in unplugged cross curricular activities.
- When we play apples and pears with a parachute, children wait until their trigger word is shouted and then run under the parachute to find a new place.
- In PE, when working in cannon, they wait for the proceeding action before performing their part.
- In singing, they wait for the preceding line when singing parts.
However, do pupils understand that the script running a broadcast command in Scratch does NOT wait for the receiver to finish the action kicked off in the receiving script before it runs the calling script’s next command? We suspect not always.
What are the Differences Between ‘Broadcast With Wait‘ and ‘Make Your Own Blocks‘ (procedures)?
Often Scratch planning introduces broadcast blocks long before make your own block. Make your own block is a way to create a procedure, and procedures act very differently to broadcast (without wait).
A script calling a make your own block, a procedure, will wait for that block to finish before moving onto its next step. The calling script stops and waits until the called procedure has finished. Plus, there can be only one make your own block (procedure) with that name. But for broadcasts, there can be dozens of receiving blocks of code with that broadcast name, even when using ‘broadcast with wait‘.
What’s a Scratch ‘Broadcast and Wait’ block
The Scratch Broadcast and Wait block is an Event block and a Stack block. The block sends a broadcast throughout the whole Scratch project — any scripts that are halted with the When I Receive block and are set to the broadcast will activate.This broadcast block lets scripts send broadcasts, and have them wait until ALL scripts activated by the broadcast end (unlike the Broadcast block, which will let its script continue without it waiting for the scripts activated by the broadcast).
Broadcasts are a good way to have sprites and scripts communicate.
Teaching Concurrency, Coordination and Procedures to Primary School Children
Usually, concurrency and coordination is an advanced topic, not dealt with until undergraduate studies. For these older learners, procedures and functions are taught early. Should we be doing the same with block-based programming languages?
Scratch and other event-based programming languages invite the early use of concurrency, and following that coordination. Many primary schemes of work exploit this before teaching procedures. It’s not clear what this means for learners’ progression in understanding of these complex concepts.
Nor is it clear as to how well primary teachers understand these different concepts, nor how well they understand the misconceptions that may be being taught.
It could be that teaching broadcast before the use of procedures is causing learners confusion and developing misconceptions. It could be that through teaching these concepts carefully in primary we reduce the risk of confusion or minimise the programming misconceptions secondary teachers then have to navigate.
Just to make things even more complicated, different block-based programming languages implement concurrency, coordination and procedures in different ways. Snap allows any sprite to control any other sprite!
Further work is needed to understand this complex area. We need to create pupil learning trajectories, learning goals, lesson activities and assessment material for teaching and learning of concurrency, coordination and procedures for primary pupils as well as CPD material for teachers to better understand the concepts and possible misconceptions.
Teaching Advanced Coding Concepts Tips
If your learners are using concurrency and coordination, and are having some problems, try the following suggestions, and see how they impact teaching and learning:
- Teach concurrency using unplugged first, using dance, gymnastics, singing
- Clearly link this unplugged work to creating a program with concurrency
- Teach coordination carefully. Maybe start with wait but move onto broadcast
- Teach broadcast as a means to coordinate action, rather than to decompose a task
- Teach using ‘make your own blocks‘ (procedures) to implement decomposition early, such as a simple ‘set up‘ script running sprite, or draw a square
- To clearly show that broadcast is about coordinating action, first teach that broadcast should finish a script (with no further commands in the same script) – like the knock knock example. This will help you see a clear flow of control through a program
- Only introduce the ‘broadcast with wait‘ command if the learner understands how it works and the difference between it and ‘make your own blocks‘ (procedures)
- Look out for creating and receiving the same broadcast within a sprite. Probably ‘make your own blocks‘ (procedures) should be used instead
- Avoid broadcasting to multiple sprites (unless the receiving sprites run independently)
Find Out More
Why not sign up for one of the CPD sessions with your local CAS Master Teacher? Or ask your local CAS hub for materials from the Diving Deep into Primary Programming Course being used to train Master Teachers in the more tricky bits of teaching programming.
Originally published in Hello World Issue 5 : The Computing and Digital Making Magazine for Educators. Above article includes modifications from the original article by Jane Waite, William Marsh, William Lau and Jon Chippindall. License CC BY-NC-SA 3.0
