Turtle Geometry - Journal - School 1

This journal is to capture what I experienced starting with Turtle Geometry (in George).

I was introduced to a teacher at a school here in Gothenburg via the wife of a colleague. I met with the teacher once during the summer, and we discussed what we would do in the fall.

Thru out this journal I will for now refer to her only as "Teacher", for the sake of privacy of school and children. Please contact me if you would like to know more, perhaps even meet her, or visit the school.

Teacher is bright and enthusiastic, experienced, well educated, and wonderful with children. She was very enthusiastic right from the start.

Session 0 - 2016-09-27

Technical test.

Just back from JavaOne 2016, and I have an appointment with Teacher to do a technical test on the schools computers after school. I was unable to complete the software by school start, and have done some late nights just to get something "good enough" that we can get started.

The machines are the smallest laptops I have ever seen. But they run Windows 7. Cool. [image of machines]

George installs and runs. Yesss.
Oh, but there is something strange: I don't see the turtle. And when I switch to "3D mode" I only see a tiny 2D grid, not a skewed 3D grid. Strange.

[screen shots]

May I borrow one of the schools machines with me home? Yes, I may.

Technical: At home I discover that that the machines do not support "SCENE3D". Actually, I am not even able to do a rotational transform about the X-axis (as this then required calculations in the 3D space).
But I need the X-axis to point up (and turtle-rotation to be counter-clockwise) to keep the geometry aligned with standard mathematics. The solution is to translate all get- and set- of Y and angle by multiplying with -1. That way the user perceives Y as up, while the underlying JavaFX graphics works with Y as down.

Also, the screen is really really tiny! For now the best I can do is to make the font a bit smaller.

Session 1 - 2016-10-06

Meet the children.

Time: 07:15. Have only slept 1.5 hours. Getting used to all-nighters now, after doing a couple at JavaOne.

Have bought lots of little SanDisk USB memory sticks. Did the last build while I showered, and copied it onto the sticks on the bus to the school.

Installed on 20+ laptops. Everything works great. Well enough, anyways.

The children file in at 08:20. They great the teacher. They see me, and have clearly been informed and are looking forwards to this. They already know me by name and ask if I will stay the whole day. Or half the day. Or at least eat lunch with them. I would love to. But another time.

I tell them a short story about a turtle - "George, The Turtle". I bring one of them up and try to show how I can tell the turtle to walk about.

Does anybody know the words for right and left in English? (Remember, these are native Swedish 8 year olds.) One does, and a couple more the remember also.

3 minutes with a project: I show them how to write (forward 50) and (left 90)

They start. They are so excited! The laptops are open and the software is already running. They open an "Input" window. Actually they click the button repeatedly, and end up opening many ... up to 7 or 8! (This should be fixed.)

They enter the command and press "Eval". Nothing happens. Ah. Parens. But it is not clear to the children that the words should be within the parens. Actually, most of them don't even know how to type parens at all! SHIFT-8/9.

Then there is the matter of the Input-window opening partially off-screen to the right, obscuring the Eval-button. Most of the children are unable to move the window to the left. Basic window management is totally unfamiliar to them. Dragging the window by its top-bar. Actually dragging anything at all is rather difficult on these machines - with tiny trackpads and a rigid button.

But they are tenacious, happy, patient, energetic. They perceiver. Some "get it" much faster than others. Some need extra help. They enter the commands and do Eval. Again. Again. The turtle moves. They are overjoyed!

But wait, the Input-window doesn't clear when pressing Eval. A bug. Well, actually, a feature: They can keep adjusting and repeating their commands without re-typing stuff. Something to think about.

After almost 60 minutes Teacher and I decide to end the session. Quit while on top. Leave them wanting more.

What some of the kids achieved is quite fascinating. See screenshots. [srceen-shots here]

Even more interestingly: We never told the kids what to do, or how to do it. They simply started experimenting and creating. Fascinating. Quite amazing.

It all played out exactly as Seymour Papert describes in his book! 35 years later, and it is equally applicable and precise. Buy it. Read it. It is a wonderful book. Papert: Mindstorms - ...

And our session was amazing.

Immediate improvements needed in software:

Session 2 - 2016-10-13

This felt like it would be a more challenging session:

First, yes the kids were indeed as excited as last time. And at the same time they were perhaps slightly more relaxed and open. They now knew me a little bit, and they had some idea about what programming would be like.

So, I started with 3 minutes of projector-time: I tried to show and explain about parens (parentheses):

(The kids still struggle with actually typing the parens (using SHIFT and ALT.GR.), and need help.

Note on software/pedagogy: Would it be a good idea to have a DnD (drag-and-drop) palette with parens, or is typing parens a basic skill that kids should simply learn. (The software already inserts a closing paren when an open paren is typed.)

The original LOGO language of Turtle Geometry doesn't require parens for most things. So doing Turtle Geometry in Clojure has a price: The understanding and use of parens. On the up-side: Once parens are understood and mastered, they have many benefits. Also, as it is Clojure and not LOGO, there is no discontinuity for the kids to continue on into the large world of (professional) Clojure/JVM programming.

I then reviewed the commands from last time: forward, left, right. Also, I emphasized the commands home and reset. Finally I ensured that the kids understood that commands (and parameters) must be within parens, for something to happen.

Then they set them to "playing" with the commands again.

Finally, some 20-30 minutes into the session, I gave them a specific task: Draw a square (and a triangle).

This turned out to be challenging for them, and for many I had to "seed" the code with one or more lines and turns for them to gradually realize how to solve this.

And of course some kids were way ahead of others, creating polygons and graduating towards circular forms.

Tips to software usage: As the code doesn't disappear from the Input (a bug that turns out to be a feature), simply have a reset at the top of the code. This will allow you to re-run your code on a blank screen every time, and you can then continue to develop your code and retry it countless times:

(reset)
(forward 50)
(left 120)
(forward 50)
(left 120)
(forward 50)
(left 120)

Pedagogical/software discussion: I could develop the software such that it might try to automatically correct the children code (by surrounding expressions with parens, and auto-correcting misspellings). But I fear that the children will then never learn what they actually did/wrote wrong. I stead I would prefer that the software gives warnings when it discovers an error, and suggests how the child might correct the error himself.

We again ended the session before the kids started getting tired and loosing interest, at about 60 minutes.

Session 3 - 2016-10-20

The plan for today is to establish a more structured thinking about a "program", and then to introduce dotimes.

Before the class started, we started all the laptops, launched George, and resized the windows so the children would immediately have a Screen and a sizable Input ready for use. The we set the laptops with lids half closed on each desk, facing away from the children.

It is interesting to note how extremely difficult it is for the children to resist touching or peaking at the computers. It is reminiscent of the "Marshmallow Test".

I started with a 2 minute discussion/questioning about what "programming" actually is? What they thought it was. And what I feel it is (and love about it).

The, using the whiteboard, I drew the turtle, and a triangle I wanted it to draw, then patiently involved the children in deciding how to best "command" the turtle to draw this triangle. It did take some time. And only a one or two of them already knew to turn left 120. Therefore I left this number undecided, and left it up to them to experiment and arrive at (hopefully) 120.

Then we wrote this (still on the whiteboard) as a set of commands. I am insistent now that they start their program with (reset). The reason for this is I want to establish in their minds the idea of a complete set of actions running from start to finish.

(reset)
(forward 100)
(left ...)
(forward 100)
(left ...)
(forward 100)
(left ...)

The children them were set to write and execute this code, and to experiment with it.

Some completed the task quickly. While others struggled with simply typing the code. And a few were uncertain about what they should do, or how or why. With the help of Teacher, we were able to guide them all to a complete implementation.
The ones who finished early were encouraged to try different distances for forward, and to swap out left with right. They spent some 20 minutes on this, and pretty much all of them felt very satisfied with their accomplishment.

(Teacher and I work very much as a team. She moves among the children, looking at their code, helping the correct mistakes, and exploring options together with them.)

Finally I admitted to the kids: "I am a bit lazy." I don't like to write the same lines of code over and over. And if I have to change something, I don't want to have to change it many places. Therefore I would prefer that I can tell the computer what to do - over and over if necessary.

Therefore:

(reset)
(dotimes [i 3]
  (forward 100)
  (left 120)
)

I did my best to explain that first the command dotimes needs to know how many times to do something: [i 3] I did not try to explain what the i is, only emphasize that they children had to use "square" parens, and to write the i and the number like that.

Then we tell dotimes what to do. This part is often called the "body".

  (forward 100)
  (left 120)

They were then given time to try to do this - some 10-15 minutes. And for those few who finished, I suggested that they try to make a square by changing the number and the angle.

One child showed me an octagon. He had done the math himself in his head: If a square is 4 turns of 90 (degrees), then an octagon is 8 turns of half that!

Another child figured out on her own that she could make a circle by doing many small steps and turns!

Thoughts after this session: It is clear that the children all struggle with basic typing and text manipulation:

Therefore, as I in future apply guides and varying degrees of intelligence to Turtle Geometry, it is well worth considering how to weave in small graphical guides and typing and text manipulation games.

Session 4 - 2016-10-27

The plan for today is keep working with dotimes, and at the end to also introduce pen-up and pen-down.

Tips: Beforehand, I had once again set up their machines - with George running and windows configured. But in stead of placing the machines on their desks, I had in stead placed them all in front of the room. This seems to be a winning strategy, as the children were much more able to focus on what I was showing them on the project. And when it was time for them to start, they simply came and fetched one computer each.

I started the session with a quick projector-demo: First I emphasized (once again) the the value of starting my program with (reset), and asked if anyone could tell me why. No-one really could, so I feel it was important to talk about.

Then I showed them (reminded them) of the standard way of doing a triangle with 6 lines of code (3 forwards and 3 turns), then showed them how I in stead would do it with dotimes:

(reset)
(dotimes [i 3]
    (forward 50)
    (left 120)
    )

Finally I showed them how I would change the code to make a square:

(reset)
(dotimes [i 4]
    (forward 50)
    (left 90)
    )

Then I set them to work. Their assignment was to first replicate the example, then to try to change it to make a pentagon, hexagon, etc.

They worked on this for maybe 20 minutes. I interrupted them twice:

Towards the end I showed them pen-up and pen-down with a simple example:

(reset)
(forward 20)
(pen-up)
(forward 20)
(pen-down)
(forward 20)
(hide)

(The command hide was new, and so they picked that one up as well, as was show.)

And I set them back to work, experimenting with these two new commands. They didn't do much with them, though - not because it was beyond them I think, but rather they were still busy working with dotimes.

At the end of the session, I left them with the following "teaser" (using nested dotimes):

(reset)
(dotimes [i 3]
    (dotimes [i 4]
        (forward 20)
        (left 90)
        )
    (pen-up)
    (forward 30)
    (pen-down)
    )

Here is another show-y example I also did on the projector in the course of the lesson:

(reset)
(dotimes [i 12]
 (forward 30)
 (forward -30)
 (left 30)
 )

Thoughts/comments:

  1. I think dotimes is a bit to complex in syntax. They don´t need to catch the i at this point, and the square brackets are a little tricky. Therefore I think I will want to implement repeat as in LOGO:
    (repeat 4
      (forward 20)
    
(left 90))
  1. It is still to clear to some of the children that certain things need to be inside parens. I think that a stronger visual cue could be useful - either in the form of colored blocks (background), or at least the indented structure that an implementation of "Parinfer" would require.

Next week is "fall vacation", so I will see the children in 14 days.

Session 5 - 2016-11-10

The plan for today is to use pen-up/pen-down. I would like the children to figure out how to write a simple program which draws 5 parallell lines above each other - like the rungs of a lader.

I start the session with a small typing exercise: Everyone has a computer and should follow my exact keystrokes. The goal is to be able to type parens, round and square, nested and in series, to delete, and to move the cursor in and out of pairs using only arrow keys and back-key.

I lead them carefully through one stroke at a time nesting combinations of parens, moving cursor in and out of pairs, deleting pairs, deleting just the right paren and then correcting the mistake, etc. We do this for about 10 minutes. It is difficult for them. I make sure to wait at every step to make sure everyone is following along.

Then I lead them one step at a time through a (by now) standard square, using dotimes:

(dotimes [i 4]
	(forward 50)
	(left 90))

Then I show them the first piece of the parallel lines exercise, discussing every command and every move of the turtle.

Then I set them to work, figuring out how to solve the exercise, hinting that they may want to use dotimes here also.

The rest of the session they spend working on this. Some solve it, others not quite. And one or two are still struggling with understanding how to make the turtle draw a line and move about. :-/

Observations/experiences

One or two of the children were very impressed with how I could mark lines and copy-n-paste code. And that I could do it with keys only (no mouse usage). I showed them how I did it. At the end of the session I also demonstrated for the whole group how fast I could write code using these techniques - to show them what was possible, but without expecting them to use it themselves immediately.

Thoughts

I believe keyboard skills are as valuable as learning to write on paper - both techniques, as well as touch-type - and so I will want to build exercises/games for this - either directly into Turtle Geometry, or as a separate application in George.

Session 6 - 2016-11-17

The plan today is to again start with a parens exercise. Then do a standard triangle. Then set them to solving the parallel lines problem. And at the end challenge them to draw a simple house using a square and a triangle.

Can they draw this face (using only keys!)?:


(o)   (o)
   [_]
  — — — 

I showed them how to draw a face using "ascii art", and they immediately saw it and loved it. I set them to do the same. The rules were: "no mouse, arrow keys only." We did this for a while.

Then we did a triangle together.

I skipped the parallel lines. I got a feeling it didn't interest (motivate) them much. I in stead went straight to the house problem.

Drawing the house turned out to be difficult, and it took most of them some time to complete the task.

Observations The kids need the time to develop. They are patient, and love doing this, and will easily continue 45-60 minutes at a time. They do get a little rowdy as time passes, but at the same time they stay on topic and don't start doing other things (except if they discover some cool turtle trick).

Also, I note with great interest that kids who previously struggled with some of the fundamentals, are now suddenly "getting it" - having "A-HA" moments, and catching up to the group.

Session 7 - 2016-11-24

I am tempted to teach the kids how to "teach the turtle words". If they can teach it "triangle" and "square", then they can compose that into "house", then many houses.

Plan for today will be: Do a triangle together, then a 5-point star together. Then let them play with that. Then teach them to "teach the turtle" "star". Then let them make a row of stars. Also, I have 2 "helpers" with me today: My colleague from HiQ (developer and UX specialist), and her 15-year old son.

What we ended up doing: Pretty much as planned.
The kids really liked working with the start, and they very quickly arrived at the correct angles when increasing the number of points to 7, 9, or more.

Understanding the concept of "teaching a new command" (defining a function) didn't seem so difficult for the children.

When I think about it, the syntax and approach is not very different from that of dotimes:

(dotimes [i 3]
  ;; body
)
(defn star []
  ;; body
)

They were all able define the function with the same ease (or difficulty) as with dotimes, and then use it repeatedly. But they didn't quite get to placing the call in a dotimes, such as:

(dotimes [i 5]
	(star)
	(pen-up)
	(forward 50)
	(pen-down)
)

Comments: I notice, with some interest, that many of the "weaker" kids are catching up quite well to the majority, even surpassing them. This goes for both basic typing and technical skills, as well as well as logical comprehension, creativity, and joy. On the other end I see also that one or two of the "sharpest" kids seem to have lost interest and drive. Perhaps I challenging these kids with special "hard" assignments, and feeding them more information might re-motivate them. The goal, after all, is not to teach the children a specific curriculum and no more, but rather allow everyone to experience growth, creativity, and pleasure at their own rate and at there own level.

Session 8 - 2016-12-01

I started the session today by immediately asking the children to write the code for a square, but without showing them how. I only asked that they used dotimes and that the square be maybe 50 wide.

They set to work. Some managed quite quickly, others required time and help (from me, teacher, or other pupil). Some of the kids that completed early then started transforming their code to other multisided shapes (pentagons, hexagons, octagons).

Next, I showed them (again) how to wrap their code in a function definition, and emphasized the similarity between (dotimes [i 4] <body>) and (defn <name> [] <body>)

They then implemented:

(reset)
(defn kvadrat []
	(dotimes [i 4]
		(forward 50)
		(left 90)))

(kvadrat)

("kvadrat" means square in Swedish.)

Then we gradually added movement and a second call:

(kvadrat)
(forward 70)
(kvadrat)

And then we put it in a loop:

(dotimes [i 3]
	(kvadrat)
	(forward 70))

At the very end I showed and tried to explain input-parameter to a function while they watched, and then showed the following:

(reset)
(defn kvadrat [längd]
	(dotimes [i 4]
		(forward längd)
		(left 90)))

(dotimes [i 5]
	(kvadrat (* i 10)))

("längd" means "length" in Swedish.) (Yes, Clojure allowed non-ASCII characters as well.)

They were amazed! I will delve more deeply into this next time. Also, maybe time to play with println.

Oh, and they haven't learned multiplication, yet! (They are only in second grade, after all.) But 2x and 10x seem comprehensible for them. So they get some implicit multiplication training as well.

Thoughts/ideas/inspirations: A difficulty for many of the children was not to write the code (dotimes [i 4]), but to understand why their code didn't execute as expected. They wrote:

(dotimes [i 4])
(forward 50)
(left 90)

Rather, they didn't easily see/understand that the movements should be within the dotimes end-paren:

(dotimes [i 4]
	(forward 50)
	(left 90))

It think it would help tremendously to have some sort of color-blocks for visualizing expressions. Then it would be more visible that the "body" (movement) is within the dotimes or not. And even more so when we get loops in loops and and loops in functions etc (i.e. deeper nested expressions).

Session 9 - 2016-12-08

My plan going in was to spend some time on dotimes and printing, then again try the kvadrat function with an input parameter.

I started by writing the following, (and explaining it), and then having them copy it:

(dotimes [i 4]
	(println "Now i is:" i)
	(println (* i 10)))

That was challenging for them - both typing-wise and to understand the prefix multiplication. (Many initially entered "i * 10"). I didn't explain the difference, only said that that is how it is. They accepted that happily.

Then, before moving on, I thought we could make one interesting augmentation:

(dotimes [i 20]
	(println "Now i is:" i)
	(forward i)
	(left 30))

I gradually increased i to 50, then 100, then 200. Wow. They loved it. And started changing their code also.

Then I suggested (and showed) that they could change the (left 30) to (left 60). Even cooler. And then I suggested they try to increase the angle even further.

WOW! I was not expecting what happened next. At 69 degrees or so, you start getting an "emergent pattern". At it was beautiful. The kids were ecstatic, and the concept spread like wildfire. I had to halt the class after 60 minutes.

Session 10 - 2016-12-15

My plan going in was what I executed on. I wanted to show how to draw a house with a square and triangle, using functions. I started by discussing how this could be done with the kids. Then I showed them the code. And finally I set them to work simply copying the code:

(reset)

(defn square []
	(dotimes [i 4]
		(forward 40)
		(left 90)))

(defn triangle []
	(dotimes [i 3]
		(forward 40)
		(left 120)))

(square)
(left 90)
(forward 40)
(right 90)
(triangle)

One of the kids suggested to do the square turning right in stead, which would eliminate the need for moving up before doing the triangle. Very cool.

For further exploration, I later suggested that they make a function ("command") called house. Also, they might make a command called move. And the draw several houses with a dotimes.

This was the last session before Christmas. I hope to have a new and improved version of the software for them when we start up after new years.

Session 11 - 2017-01-12

Plan:

So, what happened? What did we do? How did it go?

We started with a "code along". I focused on a "tiny-step-and-wait" approach - both to ensure that every single child was able to follow, as well as to maintain a good discipline. (This approach is not necessarily optimal. See "lessons learned" #4 bellow.)

I first went through (println "Hello World!"), and explained all the elements of the output. (Again see "lessons learned #5".)

I then when through (+ 2 3), playing with a couple of numbers. And again looked at the output.

Then combined the two: (println "answer:" (+ 2 3))

Then went through iterations of defining a function "plus":

(defn plus []
	(println "answer:" (+ 2 3)))
(plus)

(Before doing this second iteration, I explained the concept of parameters by showing them my coffee mug, and putting a number of die (dice) in them, then looking in it to see how many die were in it. And I had a small box I also place die in. I went so far as to write "mug" and "box" on the containers, to illustrate the point of naming. I will continue with this. Idea/tips: Use a number of similar white mugs and label them with an erasable whiteboard marker. Also, you can put anything in them... pennies, peas, pebbles, etc. That way they may more easily comprehend that the containers are similar in nature, but )

(defn plus [mug box]
	(println "answer:" (+ mug box)))
(plus 5 4)
(defn plus [mug box]
	(println mug "+" box "=" (+ mug box)))
(plus 23 24)

This is as far as we got during the lessons. Actually we went overtime - spilling in to the recess period. (This has not been a problem before. But the kids grew very impatient this time.)

We didn't do any Turtle Geometry. And the kids didn't get a chance to develop any of what they had learned more creatively. I felt I lost a good bit of "good will"/motivation/patience from the children. (See "lessons learned" #1-3)

Note for next time: Immediately show them some "wow-factor" graphics/animation, then immediately set them to replicate the basic code for that in one or more iterations, and allow time and room for creative alterations.

Conclusion. Important lessons learned: I made a couple of mistakes (not counting going past break time):

  1. The session should always contain some turtle drawing. The movements and graphics are very important to the children.
  2. The session should end with a more or less "creative period" - where the children get free regns to play with the code.
  3. Introduce perhaps only one (new) technical aspect, which the will be applies in graphics in the same session. Don't introduce something that won't be incorporated in that session, unless it is perhaps just a short "teaser" for something that will be used in the next session.
  4. "tiny-step-and-wait" is not necessarily the good taken to an extreme - especially with a larger and more diverse group: Most of the children will be able to follow quite quickly and easily, and will then have to constantly sit and wait for the one or two children who require constant attention. It quickly tires out the majority of the kids, and you risk loosing the attention and motivation of the majority group.
  5. Explaining all the details in the output, including print-outs vs return-value, is probably not very valuable. A learn-as-you-go, explain-when-necessary variant is probably better. Let the children discover patterns implicitly and then become aware of them on their own, if possible. (Also improvements to the output/textarea can make the difference much clearer right out of the box, thereby even removing the need for any special explanation.)

Session 12 - 2017-01-19

Coming directly from first session with 5th graders.

I first executed basic zigzag while they watched. They thought it was cool, and loved making sounds along with me while the turtle zig-zagged.

Then I build the god live with them, and went through the new elements with them - doing my best to help them understand how we could test if a number was even? , and how the if functioned. They seemed to understand it. Here is the basic code:

(reset)
(dotimes [i 10]
	  (if (even? i)
	    (left 90)
	    (right 90))
	  (forward 20))

I also discussed with them how to correct the direction of the zig-zag - so it would straight to the right. We agreed that the turtle had to do a right before starting. But how much? We tried different suggested angles, and ended with the result that was proposed by one of the kids: (right 45) (inserted before the dotimes).

We then had the kids fetch the laptops. We suggested that they first look at the code that the 5th graders had left on these laptops. They thought it was interesting. And easy to understand.

They then copied the code, and played with the number a bit.

The I suggested they "make a command" out of it (i.e. wrap it in a function, and then call that function:

(defn zigzag ...)
(zigzag)

And they showed and discussed how they could use it repeatedly to make something fun:

(dotimes [i 5]
	(home)
	(right (* i 30)
	(zigzag))

Many interesting results arose. Then the session was over.

Suggestion for next time:

  1. refresh this.
  2. morf the zigzag to make star-patterns, e.g.:
... (if (even? i )(left 130) (right 80))...

Session 13 - 2017-01-26

The long and the short if it: We did as suggested. First reviewing and working our way through the zigzag:

I this time focused (again) on using a white cup as the count symbol. I (again) used a whiteboard marker and labeled it i. Then explained and showed how a number (0-4) in the case of (dotimes [i 5]) get put into it, and how we then "look in the cup" to see if that number is even or not. Then I relabeled it to "ole" and changed the code accordingly. The kids apparently understood this because they then immediately started calling there parameter everything from "antonio" to "facebook", and saw how their code ran with it.

Then I suggested (and showed) that we might turn more left than right, and thereby get a circular pattern. The kids played with it and many beautiful patterns appeared.

At the end of the period Teacher had an interesting observation and a suggestion for next session: She notes that the children more often than not "stumble upon" a beautiful pattern, something unexpected but exciting. But it is rarely planned. So next time she would like them to first draw with pen and paper what they want, and then work to implement what they drew, forcing a more deliberate outcome. I like it!

Session 14 - 2017-02-02

Basically we did as planned: The children were handed a small piece of paper (A5) and asked to draw a simple figure on one side, one they knew they could program, and a more complicated figure on the other side, one they might be able to program. Several interesting things to observe:

  1. The children drew mainly abstract figures.
  2. The figures were not so far apart in shape or complexity.
  3. The children struggled with the basics - especially when it came to the difficult figure.
  4. The children sometimes modified their original drawing (simplifying it) when they came up against resistance, rather than push through in the code.
  5. The children sometimes seemed to struggle to remember how ...

Yet it was clear that the kids had fun, and felt a degree of accomplishment.

A couple of thoughts and ideas after this session:

  1. One might want to hand out a selection of ideas (projects) the children might work on, rather than just have them think of their own. This would allow the instructor to point them in new directions and trains of thought. The projects may vary in difficulty, and they may outline iterative versions; Complete the first version, then modify it to the second version, and so on.
  2. As with all other skills, repetition and timing are key. It might behove the children to program more than once per week. It seems that they struggle to remember from session to session.Perhaps, if given projects to work on, they could do one session with instructors, and then a second session with teacher only, where the second session is about completing the project from the first session.

Session 15 - 2017-02-09

After working with the 5th grade, I decided to to the first assignment with the 2nd grade.

I started by presenting them with some ideas (with marker on whiteboard) of how they might break down the problem - but without any code.

They then set to work. Most of the children immediately started with the "naive" approach; building a long list of single commands.

One child, though, immediate saw how he might break it into compassable functions. And he was entirely successful.

Here is how it might be done:

(reset)
(defn jump [x]
    (pen-up)(forward x)(pen-down)
)
(defn lines []
  (dotimes [i 2]
    (forward 120)
    (left 90)
    (jump 40)
    (left 90)))

(defn hash []
  (lines)
  (right 25)
  (jump 85)
  (left 115)
  (lines))

(hash)

Some kids, did a "backtrack" approach with right angles, rather than the diagonal jump in this code.

It is interesting to observe that the 2nd graders were able to achieve more or less the same as the 5th graders, keeping in mind though, that they have progressed slower through many more sessions to get there.

After the "winter vacation" next week, we will repeat the exercise, and then follow the same set of exercises as suggested to the 5th grade.

Session 16 - 2017-02-23

We started with a "warmup" similar to that of the 11 year olds. I wrote the following for them, and asked them replace the 3 lines with question-marks:

(reset)
(defn square []
	????
		????
		????
)
(square)

The assignment is the same as was given verbally to the 11 year olds, but many of the 8 year olds grasped it more quickly than the 11 year olds.

And then, as a second assignment, I asked them to create a pattern of squares (a 3x3 grid, with space between the squares), using the existing square command.

None of the children completed the assignment, but some (with some help) got as far as a single row of squares.

I finally builds a solution while they watched:

(reset)

(defn jump []
  (pen-up)
  (forward 25)
  (pen-down))

(defn square []
  (dotimes [i 4]
    (forward 20)
    (left 90)))

(defn square-row []
  (dotimes [i 3]
    (square)
    (jump)))

(dotimes [i 3]
  (square-row)
  (left 180)
  (dotimes [i 3]
    (jump)) 
    (right 90)
    (jump)
    (right 90))

Next time, I would like to repeat this exercise, and I would like to introduce def, which will allow them to control the row and column count from a single number:

(reset)

(def cols 4)
(def rows 3) 
(def size 20)
(def dist 30)

(defn jump []
  (pen-up) (forward dist) (pen-down))

(defn square []
  (dotimes [i 4] (forward size) (left 90)))

(defn row []
  (dotimes [i cols] (square) (jump))
  (left 180) (dotimes [i cols] (jump)) 
  (right 90) (jump) (right 90))

(dotimes [i rows] (row))

(hide)

Next Thursday the entire school will be out on field day.

Session 17 - 2017-03-09

Plan: Build a town.

Result: I showed them the execution of my code. They thought it was cool. I discussed with them quickly how they might break it down into house, then square+triangle. Then they set to work.
Several were able to arrive at a complete house, and a couple even put it into dotimes together with some form of jump.

We ended with several of them showing their results on the projector. The class applauded spontaneously for each.

It is 2 weeks since last time. In many ways it feels like we are doing 1 step forwards 2 steps back! It is clear that the children are willing and interested, but that they simply forget from one week to the next. So then the question is how to design a system (manual, aka 2+ sessions per week) and/or automatic which will allow and encourage more frequent practice and repetition. Coming from a background as music teacher, learning an instrument (skill) had the same problem. Little and often is much more effective. Better 10 minutes a day than 2 hours one day a week.

Session 18 - 2017-03-16

This time, in stead of setting the children to work on their own, I in stead went for doing a "synchronized" development session. The reason is

  1. "Learning by doing."
  2. Ensuring everyone achieves a certain level.

This went well. It took time. We didn't make it very far. But everyone made it equally far. The children were encouraged to help each other.

We made it as far as completing a no-args house command.

Next time, we will start with a star in stead, and move on to building a "star-filled" sky using rand-int. Also, encourage the children more strongly to help each other.

(reset)

(defn star [size]
  (dotimes [i 5]
    (forward size) (right 144)))


(dotimes [i 25]
  (star (rand-int  50))
  (left (rand-int 360))
  (pen-up) (forward (rand-int 100)) (pen-down))

(hide)

Session 19 - 2017-03-30

We did indeed implement the code above. Many of the children made it to completion.

They were then asked to replace the star with a house, but we ran out of time as they were starting on this task.

Session 20 - 2017-04-06

Inspired by what we did at "school 2", I decided to do almost the same thing here:

I first had them draw (on paper) a car - as simple as possible. Then we discussed it and several of them drew their suggestion on the whiteboard. In the end we ended up with a rectangle on top of two circles.

Then we started coding:
We first did a square. Then we modified it to an octagon. Then, prompted by me we agreed to try a 12-sided figure, made it smaller, and agreed it looked like a circle. Which we then wrapped as a command: "wheel" (hjul).

Then the rectangle:
First a square. Then discussed how a square differs form a rectangle, and how to modify the code. Then wrapped it in a command.

Then I had them solve the idea of a car on their own. Amongst other the initial wheel used left. But we modified it to use right in stead.

When the car was done, we wrapped it in a command, and then put it in a dotimes.

The final result:

(reset)

(defn hjul []
  (dotimes [i 12]
    (forward 5) (right 30)))

(defn rekt []
  (dotimes [i 2]
    (forward 50) (left 90)
    (forward 15) (left 90)))

(defn bil []
  (rekt)(hjul)(forward 40)(hjul))

(dotimes [i 3]
  (bil)
  (pen-up) (forward 60) (pen-down))

Session 21 - 2017-04-20

The plan is to develop a galaxy, as this coincides with what the children have been studying in science the last few weeks.

Be begin, I lead from my laptop, and they follow. We make it as far as bellow.

(reset)

(defn kurva []
  (rep 6
       (forward 10)(left 25))
  (right 88)
  (pen-up) (forward -45) (pen-down)
)

(defn galaxe []
(rep 6
     (kurva)))

(galaxe)
(forward 100)
(galaxe)

Next time, repeat the exercise, and continue - adding rand-int and stars.

Session 22 - 2017-04-27

As planned, we started at the top again.

I started by breaking down the "galaxy" into its component parts on the whiteboard. Then we set them to work.

Interestingly, most of the kids today seemed to have a rather clear idea about where to start and what was needed, and they set to work.

Most of what these children did was almost completely correct, only stumbling on minor issues.

This was very heartening!

Together, we ended up with:

(reset)

(defn jump [D]
  (pen-up) (forward D) (pen-down))

(defn arm []
  (rep 6
       (forward 5) (left 20))
  (right 70)
  (jump -25) 
  )

(defn galaxe []
(rep 7
     (arm)))

(rep 3
     (galaxe)
     (jump 100))

Notes:
At this stage, as I feel they are beginning to master the fundamental, it would be beneficial to allow them to store their code, so they can keep working on it next time. Yes, it is possible to save code in a file right now. But, because these are shared laptops with a common "pupil" account, we need a better and more robust way for them to store there code individually and safely (online).

Session 23 - 2017-05-04

In stead of completing the galaxy-exercise, I in stead was inspired to do a celestial bodies exercise. Simple: Stars and lines.

The result is bellow (Cassiopeida, I believe).

And again I notice that the kids are becoming increasingly fast and accurate int their coding - both the actual writing of the codes, as well as their understanding of how to construct the program.

(reset)

(defn star []
  (set-pen-color "orange")
  (rep 5 
       (forward 20) 
       (left 144)))

(defn line [rikt dist]
  (set-pen-color "gray") 
  (left rikt)
  (forward dist)
  )

(star)
(line -30 50) (star)
(line 45 50) (star)
(line -90 50) (star)
(line 90 50) (star)

Session 24 - 2017-05-11

The plan going in was to have the kids do something with the universe: Star-y sky, constellation, galaxies. Perhaps something like this:

(reset)

(defn jump [dist]
  (pen-up) (forward dist) (pen-down))

(defn star [side]
  (set-pen-color "orange")
  (rep 5 (forward side) (left 144)))

(rep 25
     (star (rand-int 30))
     (jump (rand-int 100))
     (left (rand-int 360)))

But I had just completed implementing speed, and had the result of a demo up:

(reset) 
(set-speed nil)
(defn hex [side] (rep 6 (forward side) (left 60)))
(time  (dotimes [i 3000] (hex (/ i 10.)) (left 3)))

And so when they saw this, they all wanted to do rotating hexagons in stead. And of course they wanted to do set-speed (which they couldn't, as it wasn't deployed yet.)

But that is what they did. And after some time several of them showed their results on the projector. It was interesting to not that by simply changing the (left 3) to another number, the results were dramatically different. Can you see a pattern? (What causes a "regular" pattern vs some sort of "spiral"? Hint: 360 / ?)

Lessons learned:

Session 24 - 2017-05-18

Today's execution went according to plan.

First I typed up the basic jump and star command, and then used them by adding

(star 30) 
(jump 100)
(star 10)

I had them copy all the code to ensure its correct execution.

Then I/we discussed how to modify it, how to use rand-int, and finally how to use set-speed to to speed up the rendering, allowing for large number of stars.

The final code is bellow.

(reset)

(defn jump [dist] 
  (pen-up) (forward dist) (pen-down))

(defn star [size]
  (set-pen-color "orange")
  (rep 5 
       (forward size) (left 144)))

(set-speed 15)
(rep 100
     (star (rand-int 20))
     (left (rand-int 360))
     (jump (rand-int 50)))
(hide)

Session 25 - 2017-06-01

The plan is was to get as far as we could with the following project:

;; commands
(defn jump [dist]
  (pen-up) (forward dist) (pen-down))

(defn skip [dist]
  (pen-up) (left 90) (forward dist) (right 90) (pen-down))

(defn zigzag [len cnt]
  (right 45)
  (dotimes [i cnt]
    (if (even? i) (left 90) (right 90))
    (forward len))
  (if (even? cnt) (left 45) (right 45)))

;; start excecution
(set-speed 15)
(reset)

;; the drawing
(def color ["red" "orange" "green"])

(jump -70) (skip -75)
(rep 4
     (dotimes [i 3]
          (set-pen-color (color i))
          (zigzag 20 11)
          (jump -155)
          (skip -8))
     (jump 155)
     (left 90))

;; a little coreography
(home)
(set-speed 8)
(left (* 360 3))
(sleep 1000)
(hide)
(skip 155)
(show)
(left (* 360 3))

The result: We made it as far as a no-args zigzag command, which we then used in a square:

(reset)

(defn zigzag []
  (right 45)
  (dotimes [i 10]
    (if (even? i) (left 90) (right 90))
    (forward 10))
  (left 45))

(rep 4 (zigzag) (left 90))

Session 25 - 2017-06-08

The last session before summer. On the one hand I wanted to continue with what we were working on the last time - the zig-zag design.

On the other hand I had just come across a very simple recursive tree pattern which I also wanted to expose the kids to before summer.

And so decided to do a little of both - first a basic square of zig-zag. Then a basic version of a recursive tree.

(reset)

(defn zz []
  (right 45)
  
  (dotimes [i 10]
    (forward 10)
    (if (even? i) (left 90) (right 90)))
  
  (left 45))

(rep 4
(zz)
(left 90))

(hide)
(reset)
(set-speed 12)

(defn tre [len]
  (forward len)
  
  (when (> len  10)
    (left 45)
    (tre  (* len 0.7))
    (right 90)
    (tre  (* len 0.7))
    (left 45)
    )
  
  (forward (- len)))


(left 90)
(tre 50)