The entries in this journal are happening in parallel with "School 1".
I was put in contact with another teacher at another school through a colleague.
She has a smaller group of second graders (age 8) - about 11 children total.
They primarily have access to iPads, but she has been able to pull together enough laptops so everyone gets their own: Mostly school PCs running Windows 7, a privately owned Mac, and a private PC with Windows 10.
Class starts at 8 o'clock, so I arrive at the school before 7, to allow enough time to install the software on the machines. It is the same version of the software as I have been running at School 1, and so it may not be perfect, but it's flaws and strengths are known and dependable by now.
I wasn't expecting a Mac, and don't have an installer ready for Mac. But fortunately I have my Mac with me and have just build a somewhat better version the night before, so I am able to first install Java and then transfer and run the bare JAR-file on the Mac directly.
Also, the program seems to install and run just fine on Windows 10, although the installer seemed to have some intermittent problems before loading properly and running.
Class begins. The teacher quickly introduces me, and I introduce myself a bit further. "Warm up the crowd" a bit. Get a couple of laughs.
I then tell about the turtle - Tom the Turtle. I don't have a toy turtle with me, but one of the kids is able to locate another toy animal. A lion. And so I am able to explain and about the turtle; about how he does what I tell him ...
I then have the children stand up by their desks, and then try to follow a couple of simple commands: (turn) RIGHT, FORWARD 2 (steps), (turn) LEFT (all the way about), etc ...
I then bring them as a group to the front of the classroom, and ask them in turn to issue commands to make one of the boys walk in a square around on the floor. Interesting to observe that the suggested sides ended up 2 step - 1 step - 2 steps - 2 steps, and when the boy bumped into the wall, one of the children was able to explain that it was because the second side was only 1 step, while fourth side was 2 steps: They weren't the same length.
Then I sat them down and showed and explained the following code:
(reset) (forward 50) (left 100) (forward 100)
(I purposefully left the angle wrong, so that it could be corrected later.)
They then set to work - some copying the code directly, others creating up to 20 line long programs freely. They did this for maybe 30 minutes or so.
As with School 1, the first thing the children had to learn was how to actually write parens. The next thing was how to create new lines and move to them, and how the arrows, Enter, and Backspace keys work. Not so easy. But useful in the end. Also, they had to master spelling "left, right, forward" correctly in English (again, these are native Swedish 8-year olds).
Towards the end, I worked through doing an actual square with them, then challenged them to try that. Some did.
And finally, I had them close their laptops, and I showed them 2 minutes of "programming magic": Quickly typing out and
dotimes to do a square, which I then transformed to a triangle, and then to a star.
Notes: Buy several small plastic turtles. They are actually also useful for the children to try out movements while working.
Idea: Could the program bring up a 3D-ish model to help map movement to 2D?
The initial plan was to remind the kids how to move the turtle, then stimulate them to figure out how to do a square on their own, and then morph that into a triangle.
As it turned out, because of the nature of the group, we did things somewhat differently. They seemed much more content to follow along with what I was doing, and skill-wise and behavior-wise they are quite homogenous.
And so we developed a square step by step together - pausing often to discuss the movements - and using a small toy turtle the teacher had acquired to help visualized left/right.
We examined what parameters to change to make the square into a triangle. (The
left got incremented gradually.) It wasn't apparent to the children that the angles weren't right when the triangle didn't fully close. In stead several were drawn to rather extending the final leg so it would reach down. Interesting.
We also used
reset, and I showed them how to "comment out" code using semicolon
Then several interesting things happened: First one student ran the code twice more, without the
reset, and since we hadn't done a final
left at the end of the triangle, it now went out in a new direction twice, causing an "hazardous" symbol. Cool!
Then others asked if they now could write anything they wanted, which they of course could, and they all started changing things excitedly.
It then struck me that sometimes we wanted to do
reset, and sometimes not. And while commenting out the first line was easier than typing and deleting it, why not simply have a separate Input-window with
(reset) in it, and so I suggested that idea, and the kids loved it.
The plan was simple and executed as follows:
First, challenge the children to write out the code for a square and a triangle. They worked studiously at this task, some requiring a little more help or guidance than others. They were encouraged to use new Input windows for each figure.
Then I showed them
dotimes, and explained and showed them how to use it for doing a square. I focused on the repetitive nature of the square (and the triangle), and their commonalities. I first had them re-implement the square using
dotimes (in new Input-windows, if they wished). Then to try to figure out how to do the same with a triangle - in the same Input-window.
Some of the children required more help than others in reasoning about the use of
dotimes for this task. But, as experience now shows, familiarity through repetition will be key.
Now they had code that drew a triangle and a square on top of each other. How to transform that into a house?!
(reset) (dotimes [i 4] (forward 70) (left 90)) (dotimes [i 3] (forward 70) (left 120))
On child had a suggestion: "Turn the turtle left, then forward then back, then draw the triangle". (Yes, this is a good solution.)
; code for square (left 90) (forward 70) (right 90) ; code for triangle
Then an alternative was proposed: Draw the square by turning right (so it goes down), then draw the triangle. Very creative!
Finally, I showed them how to transform the
dotimes code into a star.
(dotimes [i 5] (forward 70) (left 144))
They then played with that for a while before the session ended. This was the last session before Christmas. Next time will be in about 5 weeks.
First session after Christmas. The plan is to focus on
dotimes today - do squares, triangle, polygons, and stars.
We did exactly as planned - we worked our way through the different figures - doing squares, triangle, plugins, and first 1 star, then several stars.
It turned out that the kids were very clear on how many times they should repeat the "forward-left" sequence for a figure. But were more fuzzy on length versus angle to alter its shape.
I used the whiteboard to help the children think about how much to turn left - first drawing a square, then drawing a hexagon based on the first same line, so that they could see how the turtle turned a little less on that first turn (and logically the subsequent 5 turns). That seemed to help.
Because of the nature of this group of children, it is very comfortable and easy to fall into a program-along-with-me paradigm. But this robs the kids of the chance to figure things out for themselves. So next time I will make sure to start the session with simply asking them to solve a problem without any sample code. Then, from there, I think it is time to introduce the concept of "teaching the turtle new words".
As planned, I immediately started the session with simply asking the children to write a complete program that draws a triangle, and that they should use
dotimes. I wrote the commands on screen to remind them of the format and spelling:
(reset) (home) (forward ??) (left ??) (right ??) (dotimes [i ?] ??? ??? )
The teacher and I then moved about, answering questions, encouraging the kids, and helping them through some of the issues or lack of understanding. It was wonderful to see so many "a-ha" moments occur.
When done, they were asked to "morph" their code into a square, and then a hexagon. In both cases it would only require changing 2 things.
Once they got thinking, they also started improvising and creating more difficult solutions themselves.
Then, with a hexagon in place, I showed how I might want to change the rotation of the turtle and draw a second hexagon, then a third.
I then discussed with them putting a
dotimes inside a
dotimes (in stead of copy-and-paste) the original.
And finally we experimented with changing the color of the pen. This was the final result:
(reset) (set-pen-color "red") (dotimes [i 6] (dotimes [i 7] (forward 20) (left 60)) (right 120)) (set-pen-color "blue") (dotimes [i 6] (forward 20) (right 60)) (hide)
Observation: Regarding the "API": I myself initially miswrote the color-command as "set-color". Some of the children, on the other hand miswrote it "set-pen". Either way, the command is probably unnecessarily long and wordy. Also, using strings (with unknown names of web-colors") is both a bit tricky to write, and unknown.
Perhaps a basic pallette with the original TG colors, and a function
set-pen (which calls sub-functions based on its parameters):
(set-pen ???) ;; based on parameter(s), resolves to one of: (set-pen-color :<TG-color-keyword>) (set-pen-webcolor "<webcolor>") ;; by name or hex: "red" "#cc0000" (set-pen-hexcolor #rrggbb) ;; is this possible? (set-pen-componentcolor rrr ggg bbb) (set-pen-componentcolor rrr ggg bbb tt) (set-pen-thickness xx) `
Basically supporting all JavaFX
setFill types, and then some. Is this compatible with Logo TG's concept of XOR-ing colors?
Plan: Work on teaching the turtle the command "square" - the using it repeatedly - manually and with
The kids were challenged to do a square using
dotimes. I wrote the commands they needed, but didn't put them together for them.
I then showed them how we could create a command around any of these pieces of code - i.e.
Then how the commands could be repeated in a
dotimes And so it went until we were doing a basic christmas tree (of 3 triangles stacked).
Some of the kids also wanted to add a stem, and I added a star. And then we figure out how to switch colors
[Code to be inserted here]
It was interesting to observe how the kids began to understand layer by layer - with some gentle guidance from the teacher and myself. And it is interesting to observe how the teacher is also developing her own understanding of the subject, and coming up with novel ways of guiding the kids.
So the plan for today was to look at (passing) parameters. It went like this:
First I asked the kids to draw a square using
dotimes. (I wrote the needed commands on my screen, but not the solution.)
Then I showed them (reminded them) how to turn it into a command and asked them to do that. (Some were a bit confused when they had modified their code perfectly, but then forgot to invoke the command.)
Then, using the same technique as previously (a white mug and a marker), I explained and showed how to create a parameter to regulate the size of the square. (Because we wanted squares of different sizes, but without writing lots of different functions!)
The result so far was several
square invocations in a row, with "hard coded" sizes.
I then showed them the "Output", the
println, and explained the
i in the
(dotimes [i 4]...) expression, and how it related to the cup.
Finally we ended up with something like this:
... (dotimes [i 8] (square (* i 10)))
One girl did something interesting: In here
square function, she had the turtle go 6 times in stead of 4, causing him to end up in different corners after each square, and causing an interesting pattern in the above context. Try it.
Plan: Build a town! Create command
triangle, then refactor them to a generic command
shape. Create command
house, and function
jump. Is the house sized by parameter? Introduce randomness and
rand-int, maybe. Now use
dotimes to build a town!
Result: We made it part of the way. Next time we will repeat the exercise from scratch, and hopefully make it a little further. I believe it to be a good thing that the kids have to re-write the same code every session, as it forces them to consider the basic elements over and over. Repetition is key to skill acquisition. (That includes thinking as a skill!)
Here is as far as we made it today:
(reset) (defn square [size] (dotimes [i 4] (forward size) (left 90))) (defn triangle [size] (dotimes [i 3] (forward size) (left 120))) (defn hus [size] (square size) (left 90) (forward size) (right 90) (triangle size)) (hus 40) `
Here is what a complete town code might look like:
(reset) (defn jump [dist] (pen-up) (forward dist) (pen-down)) (defn shape [cnt side] (dotimes [i cnt] (forward side) (left (/ 360 cnt)))) (defn hus [size] (shape 4 size) (left 90) (jump size)(right 90) (shape 3 size)) (dotimes [i 10] (let [rot (rand-int 360) size (+ 20 (rand-int 30)) ] (hus (rand-int 50)) (left rot) (jump (+ (* 2 size))) (right rot))) (home)
As planned, we started at the top again, creating a command called square and triangle, and a command called house.
Some kids chose to skip the first two, and simply put the
dotimes inside their house command.
One girl made it as far as passing in a size argument to her house command, and then (with a tiny bit of prodding) understanding that it should be passed on to the
forward commands. Nice.
Next time, start at the top again, and see how far we get.
We started with a quick look at
rand-int. I attempted to compare it to a die (dice).
(rand-int 6). I had them try it using an Input and seeing the result in Output. When queried they did soon see that that got 0-5 but no 6. I the showed and explained how to shift the result by adding 1.
I then showed them the horse I did (the challenge from last week.)
Then we went on to the "town" assignment. Again, I had them start building a command
house. This took them the rest of the session. But it is clear that they group is progressing; more an more are able to more easily do the required
dotimes for a square and triangle, and with a little help package it in a
(defn house ...
Next time, wash, rens, repeat. Also, the challenge for next week is a "panservogn" (a tank).
Also, one of the girls asked for the code for the concord I did last week. I promised to post it online for her.
I (honestly) didn't have time to do my "assignment" at home. But I will turn it around and start the lesson by doing it in plenum - first having the children draw a tank on a piece of paper, then drawing one myself on the whiteboard, then building it on my screen with their input.
Then we will return to the house/town assignment.
Result: They were challenged by the drawing assignment itself. They didn't actually have such a clear idea of what a tank actually looked like.
I then drew one on the whiteboard, and then a simpler version of it.
Then broke the image down into circle and rectangles, then proceeded to implement rectangle. It took quite some time to coax out of them (Socratic method?) how to implement it, including passing in parameters.
Then we started building the body, tower, and canon of the thank.
But by now most of the lesson had passed, and so I said we would continue next lesson, and that they were to write a command "house" as fast as they could (in 10 minutes). One girl finished the house in 8 minutes, and then wrapped it in a command.
Thoughts: Harking back to my own "rules": Only teach what you will use that lesson, and make sure they always program something graphical each lesson. I.e., I shouldn't have spent time on implementing a
circle command this lesson, as I wouldn't have time to use it. Also, the time left for the kids to program was a bit to short. But the first part was my mistake for underestimating the time required to implement the rectangle, and the second part is remedied by the teacher (in this case) continuing with the programming after I left.
[picture of whiteboard here] [code here]
A great session today!
Basically, we started by having the kids build the command "house". Everyone succeeded, some requiring a little more help than others in organizing their thoughts and getting the logic and nesting of commands right. Several got as far as passing in a size-parameter to their command. I then (after about 40 minutes) did the same code while they watched, (interacting with them as I went, of course). Then we completed the "tank" from last time. [kode here]
Plan: Draw a car. First have everyone draw a car on paper, then on the blackboard. Then we "break it down" together. Then they attempt to implement it on their own. The simplest form should be 2 flat rectangles stacked and a couple of circles.
(reset) (defn rekt [B H] (dotimes [i 2] (forward B) (left 90) (forward H) (left 90))) (defn wheel  (dotimes [i 36] (forward 5) (right 10))) (rekt 200 50) (forward 20) (wheel) (forward 120) (wheel) (forward 65)
Easter holiday has passed, i.e. 2 weeks since last time. The plan today is to challenge them to repeat as much as possible of the car on their own. Then go on to populate a road - first linearly, an then perhaps with a bit of randomness.
Result: After a lot of hard mental work, pretty much all the children were able to complete a 2-arg
rect command. Some made it as far as starting on a circle. Next time: Repeat! (Again, have the children construct a rect command and a circle command, and then combine them to a car.)
We picked up where we left off - with building a car from a 2 param
rect command and a 0 or 1 param
circ command. The kids are both displaying a good understanding of the basics, and seem to really be enjoying mastering it.
Next time will be the last time before summer.
I had prepared a file containing the basic code for
car from last time.
The plan was to do E6 (a highway through Scandinavia).
I showed them how to find and load the file (from their Desktop) into "Code". This worked nicely, but there turned out to be a bug (which has been corrected in George 0.8.1) that caused certain input numbers to the size of the car to through an exception. So, while some were able to do car, others were not. (I was unable to debug the cause and suggested a workaround during class.)
Therefore I fear we ended on a bit of a low note.
This was our last sessions together for now. Thank you to the teacher and the 11 children for the time we spent together. I have loved the time we have spent together.