Programming class (grade 5 and 6)

Grade 5

Homework
We started out with everyone showing their homework programs (drawing our names in Thai and English) and telling us one thing they really liked about the program and one thing that they found challenging.



Here are a couple of highlights from the discussion

1. Repurposing commands: Tatia and Chunly both made use of dots instead of drawing explicit curves. This led us to talk about two different approaches: getting a program to implement a known method (e.g., draw your name the way you would move your hand) vs inventing a new method that uses the tools the computer already knows. There are strengths and weaknesses of each approach and the name programs show a mix.
2. Reusing code: when do you write something new or just use code you have already written? We compared these two programs พิชชี่  and Pitchee. In the first, every component/character of the name is drawn with unique code, even though there are two identical letters (ช) and the vowel _ิ is a subcomponent of _ี. In contrast, the English version has two e's that are drawn with identical code. 
3. Simultaneity: Jung was the only one (including last year) to have the idea of using multiple turtles to draw different components of her name. This extends the first point of our discussion: doing things with the computer differently than our organic methods. we only touched on this briefly, but it will be good to return to it.

Multiple turtles
Again, we talked about syntax related to hatching multiple turtles. This time, we started with this code:

e = hatch plume.b = hatch redb.fd 100

The puzzle was: why doesn't turtle b (our red one) move? Two possible corrections:

• change the second line to b = hatch red
• change the third line to e.b.fd 100

We talked a little about what e.b meant in the second line and whether we would prefer the first correction or the second correction.

For loops
After the homework conversation, I wanted to continue the theme of using repeated code, the idea that the computer will faithfully and precisely repeat the same commands again and again. The idea that this is a major difference between a machine and a person, and to start finding ways to make use of that.  Naturally, looping provides a key example.

To start, we wanted to get the mechanics right with a simple square:

pen blue
for [1..4]
  fd 100
  rt 90

Even doing this, there are a lot of little details to discuss:

• what is this funny punctuation: "[" ".." and "]"
• why do the third and fourth lines have to be indented? what if they aren't?
• the different views between code and blocks. This is one case where the blocks really work nicely to show the commands captured by the loop

After this, we did several experiments:

1. adding a new command to the loop (for example, making a dot at each vertex)
2. changing into a triangle instead of a square
3. modifying the size of the shape
4. moving commands into and out of the loop

Possibilities for next time
There were many ideas I'd prepared for class that we didn't have time to cover:

• play command and Piano
• ABC notation
• Take a look at gym.pencilcode.net/jam
• Thai Flag

Homework
The challenge this week is to draw a 2 color yin-yang like in the center of the Korean flag. This is mostly an exercise in understanding arcs, but let's see if anyone uses a for loop or multiple turtles!

Grade 6

Debugging
I wanted to continue some of the if and or ideas from last time. In addition, all of the students have been a bit stuck on their projects because they are having trouble understanding code examples from other people's programs. I thought that some debugging work would be helpful for both of these.

Challenge 1: This program (from last week) has an error: TurtleRace. What is wrong? How can we investigate?

Since we had seen a complete example of this program last time, everyone understood that turtle boongie was not making the dots that were intended.

We explored several strategies to investigate why this was happening:

1. comment out lines of code using # or sections of code using ###: This let's us investigate whether a particular code is causing a problem, not doing what we intend, or simply not doing anything. For example, in our turtle race program. commenting out line 30 does not change the output. That tells us something is wrong.
2. Add test code that has a function we clearly understand. In particular, for conditional statements, we can add code that helps us verify whether the conditions are being treated the way we want. In this case, we could have added a new drawing command at line 31 or a write to give us a message.
3. reduce the number of iterations and trace line by line: this is a brute force approach. 

The error in this program is subtle and an example of something that often happens: we have a slight error, but the overall line of code looks familiar, so it makes it harder to spot the problem.

Challenge 2: My program doesn't work properly: FactorGameWindows.

1. How do the windows move and how does the program make them stay along one line?
2. What doesn't work properly?
3. Can we fix it?

This is a much more complicated challenge, partly because the code is more complex, but also because the program itself is less familiar. However, investigating this program was part of the homework for both Titus and Win, so really this challenge amounted to working on the homework together.

Some of the earlier techniques for debugging came back into play. In particular, Win experimented by commenting out code and seeing the effect.

Projects:
Challenge 2 amounted to project work for Titus and Win. For the other two, we had private conversations about
- The program Sounds with Boongie
- Correction to bomb program for Gun

Homework
- Titus: (same as last week) make a rocket that moves side to side
- Win: (same as last week) make a care that moves side to side
- Gan: combine the bomb code with the target+points programs to complete his project
- Boongie: get more sound-file links from