Open Source In The Classroom

OSCON 2013 Speaker Series

To teach computer programming to a young person with no experience, you must imagine what it’s like to know nothing about languages, algorithms, data structures, design patterns, object orientation, development tools, etc. Yet the kids I’ve seen in high school over the past several years are so immersed in a world of computing, they have interesting partial understandings of how things work and usually far deeper knowledge of what’s being done with the technologies at a consumer level than their teacher. The contemporary adolescent, a child of the late 1980’s and early 1990’s, has lived a life that parallels the advent of the web with no experience of a world before such powerful new verbs as email, Google, or blog. On the other hand, most have never seen the HTML of a web page or the IP address of a networked computer, and none of them can guess what a compiler does. As a high school computer programming teacher, I am usually the first to help them bridge that enormous and growing gap, and it doesn’t help that the first thing they ask is “How do I write an app for my phone?”

So I need to remember what it was like for me to learn programming for the first time given that, as a child of the early 1970’s, my own life parallels the advent of the home computer. I go backwards in time, way before my modern toolkit mainstays like Java, XML, or Linux (or their amalgam in Android). Programming days came before my Webmaster days, before my analyst days, before I employed scripting languages like Perl, JavaScript, Tcl, or even the Unix shells. I was programming before college, where I used older languages like C, Lisp, or Pascal. When I fondly reminisce about banging out BASIC programs on my beloved Commodore-64 I think surely I’ve arrived at the beginning, but no. When I really do recall the very first time I wrote an original computer program, that was even longer ago: it was 1984. I remember my seventh grade math class, in a Massachusetts public school, being escorted into a lab crammed with no more than a dozen new Apple IIe computers. There we wrote programs in a language called Logo, although everybody just called it “turtle”.

Logo, first created in Cambridge, MA in 1967, was designed from the outset as a programming language for teaching about programming. The open source KDE education project includes an application, KTurtle, for writing programs in Turtlescript, a modern adaptation of Logo. I have found KTurtle to be an extremely effective introduction to computer programming in my own classroom. The complete and well-written Turtlescript language reference can be printed in a small packet of about eight double-sided pages which I can distribute to each pupil. Your first view is a simple IDE, with a code editor that does multi-color highlighting, an inspector for tracing variables and functions, and a canvas for displaying the output of your program. I can demonstrate commands in seconds, gratifying students with immediate results as the onscreen turtle draws lines on the canvas. I can slow the speed of the turtle or step through a program to show what’s going on at each command of a larger program. I can save my final output as an image file, having limited but definite value to a young person. The kids get it, and with about 15 minutes of explanation, a few examples, and a handful of commands they are ready and eager to try themselves.

A modern paradigm of teaching secondary mathematics is giving students a sequence of tasks that give them a progressive understanding of concepts by putting them in situations where they struggle enough to realize the need for new insights. If I ask the students to use KTurtle to draw a square, having only provided them with the basic commands for moving the turtle, they can quickly come up with something like this:

reset
forward 100
turnright 90
forward 100
turnright 90
forward 100
turnright 90
forward 100

If the next tasks involve a greater number of adjacent squares, this approach becomes tiresome. Now I have the opportunity to introduce looping control structures (along with the programming virtue of laziness) to show them a better way:

reset
repeat 4 {
  forward 100
  turnright 90
}

first_tasks

As I give them a few more tasks with squares, some students may continue to try to draw the pictures in one giant block of commands, creating complicated Eulerian trails to trace each figure, but are eventually convinced by the obvious benefits and their peers to make the switch. When they graduate to cutting and pasting their square loop repeatedly, I can introduce subroutines:

learn square {
  repeat 4 {
    forward 100
    turnright 90
  }
}

reset
square
forward 100
square
turnright 90
square

I can even alter the tasks, by saying I now want the squares to be smaller. The students can all see the problem of having to change the number 100 everywhere it appears, and so I can introduce variables and arguments to get them to something like:

learn square $s {
  repeat 4 {
    forward $s
    turnright 90
  }
}

reset
square 50
...

If the figure is string of adjacent squares, they can even start to see the value of nested subroutines:

...
learn snake $l, $s {
  repeat $l {
    square $s
    forward $s
  }
}

reset
snake 5, 50

I get the class to this level of algorithmic thinking in one or two 40-minute class periods. They all experience the code-test-debug cycle but there’s no difficult syntax, no libraries to import, no enforced file structure, no compiling, and no licensing fees. We can extend this initiation to harder and more interesting tasks. Turtlescript has commands for graphics as well as mathematics and some primitive I/O including (new) input validation. Students experience variables which they can assign numbers, strings, or Boolean values. These variables can defined explicitly, assigned values through common math, Boolean, or comparison operations, or even through randomization. Turtlescript has most common control structures, such as repeat, while, and for loops, if/else decision chains, break and wait statements. Through the learn command, as the above demonstrates, students begin to see the potentials of subroutines, nested routines, and arguments. I even use the idea of commenting code to motivate software engineering. It may seem like just pictures and there is inherent constraint (my course moves on to object oriented programming after a few weeks), but I could easily use KTurtle to demonstrate advanced math concepts in geometry, trigonometry, probability, or recursion. Seek and you’ll find instances of professionals using KTurtle in sophisticated ways, to draw Sierpinski fractals or model plant growth patterns using Lindenmayer Systems for example.

imagination

KTurtle is in the most powerful class of educational tools: the sandbox application. I turn the students loose on their own creations, and without much intervention or explanation they are free to play, experiment, and learn. The education is happening in parallel, and the students all describe the experience as fun. I can identify learners with an aptitude for algorithmic thinking just as the students themselves can identify if software development is a career they might find fulfilling. The true limiting factor becomes their imagination, and I enjoy seeing what they come up with or how they find and eliminate the bugs that get in the way. Best of all, it happens without once saying “Hello World” or trying to explain to a curious kid that’s never written a line of code what public static void main(String[] args) means.

tags: , ,