Teach programming to children

Teaching programming to children is a project that grew from a conversation at the Fourth European Tcl/Tk Users Meeting in 2003.

Resources edit

Elementary Computer Graphics: Drawing with Pixels ,Michael J. Norton ,2003

Description edit

Arjen Markus 2003-06-05: The idea grew over breakfast in the hotel in Nuremberg, where Clif Flynt, Pascal Scheffers, Richard Suchenwirth and I stayed for the Fourth European Tclers' Meeting (Andreas Kupries stayed at the same hotel, but we were earlier to rise):

let us develop a program that allows young children to learn how to program in a playful way. The basic principle is simple:

It is a drawing program where you type in commands
The graphics cursor is, for instance, a puppy dog
The commands can be simple or composite, so that the child will learn to think in structures

Of course, over breakfast the thing grew into an intelligent life-form: as the child uses the program longer, the puppy would grow, increasing in size and showing different behaviour. Or what about ways to draw the actual lines and so on: wagging tail, sniffing on the ground, dropping droppings ...

AM: For those interested: there is a project on tcl.projectforum.com - see [1] where writing began. More contributions would be in order.

AM 2009-11-25: I have revived this project: I am using the pdf4tcl extension to generate a nice-looking PDF document (easier to distribute, with embedded pictures and all). The Wiki-like mark-up is being processed with a little program, so that I can easily edit the files and do not need to rely on some word processor of sorts. It also makes it easier to embed the code for the pictures ;).

If you are interested in the document so far, drop me a note.

JM 2012-07-04: Arjen, is this project still alive? I think a format like what you describe could be a boost for this to attract more audience...

AM 2012-07-05: It is slumbering ... I have finished another book project a few months ago and I have been thinking about this one again. It is however a matter of finding time and energy to get working on it. And the first project on the agenda is a holiday.

JM 2012-07-05: Enjoy the holidays and let me know if I can be of any help with this project.

AM 2012-07-06: Now that sounds rather interesting. I will let you know :).

Details edit

Basic (Tcl) commands are:

lines $thickn - set the line thickness
colour $name - set the colour for drawing
start line - record the current position of the graphics cursor
draw line - draw a line from the last stored position to the current one and store the current position
move $dist - move a certain distance
turn left|right - turn the direction over 90 degrees
draw circle - draw a circle
fill circle - draw and fill a circle

The commands as shown above are a bit abbreviated and serve merely for the discussion (see below).

A user will type in something like (in this case, a Dutch kid :):

teken heel groot rondje

This gets translated (using a very straightforward word-by-word approach) into:

draw very big circle

Which is in turn analysed as:

command=draw
object=circle
attribute=big
qualifier=very
names={}
numbers={}

And run as the command:

$command $object $attribute $qualifier $names $numbers

(each actual Tcl command will have this signature)

This way, our kid user can type:

I want to draw a very big circle

or:

teken hier een grote cirkel

(draw a very big circle here)

This allows rather casual use of the commands with the possibility of ambiguity and misinterpretation...

Question: should we try to repair typos? If so, what is a convenient way of doing this?

Question: can we use [msgcat] for the translations? It is in some way going the other way around when compared to the usual use.

The code below translates Dutch sentences into Tcl commands like decribed above

# kid.tcl --
#    Some experimental code to translate sentences to commands
#

namespace eval translations {

   namespace export mc translate

   variable dictionary {
{line obj lijn}
{big attr grote groot}
{small attr klein kleine}
{circle obj cirkel rondje}
{square obj vierkant}
{draw cmd teken}
{fill cmd vul}
}         

proc mc {word} {
   variable dictionary

   foreach d $dictionary {
      if { [lsearch $d $word] > -1 } {
         return [lrange $d 0 1]
      }
   }
   return [list $word ?]
}

proc translate {line} {
   set words   [split $line]
   set names   [list]
   set numbers [list]

   foreach v {cmd obj attr qual} {
      set $v ""
   }

   foreach word $words {
      if { [string is double $word] } {
         lappend numbers $word
      } else {
         foreach {translated type} [mc $word] {break}
         if { $type != "?" } {
            set $type $translated
         } else {
            lappend names $word
         }
      }
   }

   if { $cmd != "" } {
      puts "$cmd $obj $attr $qual $names $numbers"
   } else {
      puts "$cmd $obj $attr $qual $names $numbers"
      puts "[mc "Unknown command:"] $line"
   }
}

} ;# End of namespace

#
# Test the above code
namespace import translations::*

puts [mc "teken"]

translate "ik teken een grote cirkel"
translate "vul klein vierkant"

Here are some basic drawing commands - nothing fancy yet and not hooked up to the translation procs

namespace eval drawcommands {

   namespace export colour thickness move turn draw start stop lines

   variable colour    "black"
   variable thickness 1
   variable posx      200
   variable posy      200
   variable dirx      1
   variable diry      0
   variable anchorx   {}
   variable anchory   {}
   variable prevx     $posx
   variable prevy     $posy


proc colour { obj attr qual names numbers } {
   variable colour
   set colour $obj
   .draw itemconfigure "cursor-centre" -fill $colour
}

proc lines  { obj attr qual names numbers } {
   variable thickness
   set fullword "$qual$attr"

   switch -- $fullword {
   "verythin"  { set thickness 1 }
   "thin"      { set thickness 3 }
   "thick"     { set thickness 6 }
   "verythick" { set thickness 12 }
   default {puts $fullword}
   }
}

proc move { obj attr qual names numbers } {
   variable posx
   variable posy
   variable dirx
   variable diry
   variable prevx
   variable prevy

   set dist [lindex $numbers 0]
   set delx [expr {$dirx*$dist}]
   set dely [expr {$diry*$dist}]
   set posx [expr {$posx+$delx}]
   set posy [expr {$posy+$dely}]
   .draw move "cursor" $delx $dely
   .draw coords "anchor-line" $prevx $prevy $posx $posy
}

proc turn { obj attr qual names numbers } {
   variable posx
   variable posy
   variable dirx
   variable diry

   set oldx $dirx
   set oldy $diry
   if { $obj == "left" } {
      set dirx [expr {$oldy}]
      set diry [expr {-$oldx}]
   } else {
      set dirx [expr {-$oldy}]
      set diry [expr {$oldx}]
   }
   # TODO: rotate cursor
}

proc start { obj attr qual names numbers } {
   variable anchorx
   variable anchory
   variable posx
   variable posy
   variable prevx
   variable prevy

   if { $obj == "line" } {
      if { $anchorx == {} } {
         .draw create line $posx $posy $posx $posy -tags "anchor-line"
         .draw raise  "cursor"
      }
      set anchorx $posx
      set anchory $posy
      set prevx   $posx
      set prevy   $posy
   }
}

proc stop { obj attr qual names numbers } {
   variable anchorx
   variable anchory
   variable prevx
   variable prevy
   variable posx
   variable posy

   if { $obj == "line" } {
      .draw delete "anchor-line"
      set anchorx {}
      set anchory {}
      set prevx   $posx
      set prevy   $posy
   }
}

proc draw { obj attr qual names numbers } {
   variable anchorx
   variable anchory
   variable posx
   variable posy
   variable dirx
   variable diry
   variable prevx
   variable prevy
   variable colour
   variable thickness

   if { $obj == "line" } {
      .draw create line $prevx $prevy $posx $posy \
         -fill $colour -width $thickness
      .draw raise  "cursor"
      set prevx $posx
      set prevy $posy
      set anchorx $posx
      set anchory $posy
   }
}

};#End of namespace


#
# Auxiliary proc to delay execution of the commands
#
proc delayed {delay body} {
   set time 0

   foreach cmd [split $body "\n"] {
      after $time $cmd
      incr time $delay
   }
}

canvas .draw -width 400 -height 400 -background white
pack .draw -fill both

.draw create oval 195 195 205 205 -fill black -tags {"cursor-centre" "cursor"}
.draw create oval 195 195 205 205 -outline black -tags "cursor"

namespace import drawcommands::*

delayed 250 {
   start line {} {} {} {}
   lines {} thick very {} {}
   colour green {} {} {} {}
   move {} {} {} {} 100
   draw line {} {} {} {}
   turn left {} {} {} {}
   move {} {} {} {} 100
   draw line {} {} {} {}
   turn left {} {} {} {}
   move {} {} {} {} 100
   turn left {} {} {} {}
   move {} {} {} {} 100
   draw line {} {} {} {}

   stop line {} {} {} {}
   move {} {} {} {} 100
   start line {} {} {} {}
   colour red {} {} {} {}
   lines {} thick {} {} {}
   move {} {} {} {} 100
   turn right {} {} {} {}
   move {} {} {} {} 100
   draw line {} {} {} {}
}

Lars H 2003-06-06: The idea that one should use Tcl/Tk for teaching programming to children has been on my mind for quite a while now. Many aspects of Tcl that seem strange to adult programmers are quite natural to a child:

Children shouldn't find expr prolix to use, because they spend several hours a week doing sums and know from recent experience that these aren't as easy as many other languages would make us believe.
Basic string operations (split, join, string, etc.), on the other hand are rather easy to explain to a child, but prolix in more traditional computer languages.
The idea that Everything is a string, in the sense that there isn't any information that is hidden from the string representation, is also something that should appeal to children. Magic might be fun to look at, but there is also the desire to get to know how the tricks are done.

(Sometimes I even feel conspiratorial about the whole idea. If Tcl can be thought to the world's youth today, then in ten years time it will dominate the world!)

I am however unsure whether the approach sketched above will be of much use. It is creating a sandbox language built up around a collection of features that are expected to suit the focus group, but there isn't all that much one can do with them. There is a definite risk that the command language (full sentences in the child's mother tounge) is considered too prolix in comparison with the effects one can get out of the thing controlled. One language which very much went that way is AppleScript (which can provide a surprising amount of control of one's Macintosh), but we haven't seen that used to teach children programming, have we? Thinking back to my own childhood, I didn't have any trouble with using Basic commands such as RESTORE even though I didn't understand it as an English word. Using full sentences in text based adventure games was OTOH not a goal; most commands followed a simple <verb><noun> pattern, and more complicated constructions such as

KILL TROLL USING SWORD

felt overly complicated. A problem with basing command languages on natural language is that children will quickly be disappointed when the computer fails to understand perfectly valid natural language commands because the words aren't in the expected order or something like that. If they continue, they will discover that most of the details in the natural language are unnecessary and therefore stop including them, after a while arriving at the actual command language. However for the sake of imitating natural languge, the command language has probably sacrificed a lot of its power (control structures, variables, etc.) and then there isn't much point in having it.

Setok: "Me too". For quite some time I have been thinking about using Tcl to teach children to program. The way I see it, a language should be simple enough for children to program. If it's not, something needs to be done about it. I also don't believe in inventing an artificial language for children. Perhaps providing easy procs to make some things simpler (but then again, I also believe these procs should enter general use if they really are simpler). In fact, I usually hate tools which are made for educational purposes. I learnt a version of BASIC when I was 8. Sometime later I found the tortoise programming thing a waste of time. I'm sure other children could be the same.

JBR: I Thought that this was called Logo

AM: I should read more about Logo, I guess, but my intention is not so much a drawing language (isn't that what Logo is all about?) as well as a simple programming "language" that is more suitable for children than ____ (fill in any language you want).

It is also my first - hm, no, second - attempt to use natural language in a programming context. (My first was an unsuccessful entry to the Obfuscated C Contest)

Setok: But why? If the language is simple, and useful, why design it just for children? I'm not into pain and torture (much), so I want things as simple and easy as possible, child or not. I think some also underestimate the intelligence of children here. I doubt they will have any problems whatsoever in learning a command-oriented language. I didn't so why should today's children be any different?

WHD: A couple of comments. First, regarding natural language--I think this would be a big mistake. Your "draw very big circle" seems nice and simple, but it's really very sophisticated. It's easy to use if someone tells you to type "draw very big circle", but you need a complicated mental model to know what other commands are valid. In other words, many commands that seem like they should be valid won't be, and many commands that are valid will be non-obvious. This doesn't aid understanding in the long run, however enchanting it might be in the short run. Instead, provide some basic primitives and a simple way to compose them, and the kids will eat it up.

Second, regarding graphics a la logo--I'm with Setok, defining a simplified language seems counter-productive to me. Tcl is already as simple as it needs to be for the job. On the other hand, a kid's not going to want to just play with a programming language; he's going to want it to do something neat. That means we need to provide a problem domain. I can think of several:

"Teletype"-like computer games, like the old BASIC Star Trek games, where the user interface is provided via INPUT and PRINT. This is a nice simple I/O model for kids to master. It's also so dated as to be refreshingly new. Tcl doesn't support this directly as nicely as you'd think. (I've done some work along these lines.)
A graphics world, a la Logo. Kids can use Tcl commands directly to draw things, and they can write new commands. A Turtle Graphics kind of system would be appropriate. (There are examples of this on the Wiki already, I believe - yup: Turtle graphics the Logo way).
Some other interesting simulation world, possibly with really fancy graphics, this is controllable by Tcl commands and amenable to scripting. A railroad train layout, for example, with lots of moving parts in addition to the trains.

And then, when the kids want to do something else, they can use plain Tcl.

ZLM 2003-06-13: "Me too". I have thought about this before, but lazyness and Tcl-illiteracy prevailed. I was thinking more in the context of groups of children (school activities, holyday camps and so on). Some thoughts:

Prepare an activity plan /coursework /whatever , so that anyone could teach a little programming class based on that.
I imagined a tool similar to what WHD describes above as a "simulation world". Something more like a game, a set of puzzles that have to be solved by entering Tcl commands. Each level wound bring in new features. There would be an interactive shell that could provide clues and corrections. A hybrid of TclTutor and The Incredible Machine...
What is the minimal subset of Tcl that can be useful?

See also a recente Advogato article ( The Little Coder's Predicament - http://www.advogato.org/article/671.html

) and this Slashdot discussion about it: [2] . One sentence from the Advogato article: "You've got to be able to write a single line of code and see a result".

See also Squeak (http://www.squeak.org/

) and Squeakland (http://www.squeakland.org/

Lars H 2003-06-13: I suspect that one should start with putting up a programming (or perhaps rather development) environment that is simple enough for a beginner (child) to use (without restricting the Tcl one can use in it). There should be an "edit" window where one can write procs and other code that is saved with the project. There should be a "console" window where one can type commands that will be evaluated immediately. There should also be some kind of a "world" window with things such as those described by WHD above. These things can probably be made very tricky, but to begin with it would certainly be sufficient to have: one project per process and one "world window" of each type per project. One should not restrict the use of toplevel and such, so it would be possible to open new windows, but they wouldn't be as nicely managed as those that were prepared (the child would have to face up with the grim reality).

Some things which this development environment must be able to handle, and which I fear is not altogether easy, are:

It must be possible to stop runaway scripts without messing up the environment. It would also be good if one could have them continue execution again (possibly after changing some variables), but that is not essential. All this is something that should be possible to steal from a debugger.
It should not be necessary to explicitly resource code in the "edit" window after having changed it; the development environment should (at least by default) keep track of what has been changed and try to evaluate it automatically as necessary. The reason is that it is very, very easy to forget to resource the changes. Removing this obstacle can do a lot in usability.
There should be documentation and tutorials in the mother tongue of the child. (Of course, nothing stops us from doing everything for English-speaking children first, and then translating.) The obstacle a foreign language (even one everybody learns at school) presents is easy for us computer nerds to overlook, and should be avoided.

AM 2003-06-19: So, the conclusion is:

Do not attempt to use "natural" language
Do not attempt to provide a simplified language

Instead:

Provide a working environment that is easy to use by the young programmer-in-spe.
Provide convenient sets of commands to work within a specific "miniature world"

Well, this seems doable :)

AM 2003-06-19: I have started reading up on LOGO. My first conclusions about that are that it is a pity that there were/are so many dialects (one was Tandy Color Logo, conveniently abbreviated to TCL in the book by Boris Allen :) and that Tcl (ours) would be perfectly capable of providing a very portable implementation of the ideas - just continue with the work already published here and turn it into a starkit.

With the proper interface/working environment, it could become a very useful tool.

Todd Coram: Alan Kay thinks that kids deal with concurrency a lot more naturally than we corrupted adults do. The Morphic environment (world) in Squeak Smalltalk is made up of lots of little concurrent tasks. Each graphic element has its own little script that runs independently from others. Modern Logos are designed with concurrency in mind. Some fantastic actor-based educational micro-worlds have been written in Logo (MicroWorld Logo, Super Logo, etc). ToonTalk is another (massively) concurrent programming environment geared towards kids. StarLogo is a massively concurrent language for doing real-world simulations for teens.

There is a huge amount of ideas that can be stolen from Logo and Smalltalk (Squeak specifically). (I think ToonTalk misses the boat, but has a very, very interesting programming model --- no functions/procedures only collaborationg processes -- sort of a very radical Erlang).

TV 2003-06-19: After seeing the page show up on the recent changes[3] wiki page, my first response, being the natural cynic I was already when I was teenager when it concerns positive definitive statements, or lets say easily being a fundament scientist, was: do we want to ?

I don't have children of my own (to my knowledge), but I've been near and dealt with more than enough to wonder why it would *have to be* that one teaches them to program.

Maybe they just want a good web TV and interactive phone, some fun games, a movie encyclopedia, a calculator, and what else.

Then again, I wanted to program when I was a kid, though not badly at first in the way which is mostly known. I had a book on the 8080 from some sale when I was I guess around 12, and found von Neuman architectures one of the most challanging digital circuits, which I actually built at the time of cheap digital parts (meaning 7400 series parts and breadboards). I'd be into the thrill of finding a good and efficient hardware way to scan a keyboard. And my programming interests would be how to get a microprocessor to do a multiplication out of additions. I played soccer on the street to, but you know, I found that challenging.

Would average primary school or teenage kids find it a challenge to play around with dogs running around a screen? Some, maybe. I found Z80 assembly challenging, because it could make me do things which I otherwise couldn't get done, taking those 2 megaclockcycles per second and realing making the processor tick, I found challenging when I was 13 and a bit later I'd use the principle to make digital sounds.

I liked basic also because it would make me do things I otherwise couldn't: language (string) handling, graphics, fun stuff. I was interested in physics (and good at it) so I liked to make the difference equations of virtual atoms tick and display the particles on the screen.

As a little kid, there were no computers (around) yet, and I guess I would be more interested in a radio, a racetrack, tape recorders and movies than something a nintendo would do a lot more challenging than LOGO would. Though I second the opinion that learning to think about what structures are about is important and probably important teaching children. Like they learn math, and geography.

Todd Coram: See Mindstorms by Seymour Papert. Learning to program (and I don't mean IT dept style -- or even computer science) teaches you a lot more than about computers. It teaches you how to think about problem solving. Cause and effect. How to plan. How to design. How to explore ideas. Now, I am talking mostly about older children (over 8 yrs old). Younger kids need to know how do deal with three dimensions. They should be playing, climbing, putting things together and taking things apart -- exploring their world. On the computer, you can invent things that you can only imagine. Things that are not physically feasable to do. Using StarLogo, kids program their computers to simulate traffic jams (to learn about traffic patterns -- why is that highway always jammed?), ant colonies and other ecological systems. They program to learn about things. Nintendo can't do that. Logo/Lego kids learn about physics by building and programming lego robots (Are 4 wheels better than 3 wheels on a car?).

Mind you, what passes for computer programming (and usage) in schools to day is a crime. No, my kid doesn't need to know how to program Java/C/C++/Perl/Python/Tcl. But, he would benefit from learning a programming language to help express himself and explore ideas.

BTW, should we teach kids how to program Tcl? Yes and No. Squeak Smalltalk is too complex in my mind (although it comes closest to an ideal interactive environment). It has too much syntax. Tcl, on the other hand... Study Morphic (Squeak's graphical environment). All of this can be done in Tcl/Tk and without classes (the original ideas behind Morphic come from "self" a prototype-based language).

AM 2003-06-20: I think my primary goal would be to help children learn to program (that is, to analyse the problem or question they have and to construct a "mechanical" solution or algorithm for it. For me, Tcl seems the perfect vehicle to achieve this - in one form or another.

My secondary (conspirational, if you like) goal would be to make them familiar with Tcl as a programming language.

My elder daughter, six and a half at the time I am writing this is very much interested in learning to use a computer, to play games (but not for the sake of games only - she can not stand losing :) and to learn in general. So, I do have a very personal interest in this subject.

TV: Did I hear lego? That's good. I liked Lego as a kid, though I was a boy, of course, but I'm sure there are girls who like that, too. Building cars, gear boxes (it was in the time technical lego was 'invented' and just marketed) cranes, opening bridges, I even made a X/Y plotter at some point with a card reader to drive the motors (like a paper piano roll, letting wires make contact through the holes). Wonderfull.

Mecano (if that rings any bells with oversees territories), metal strips with holes and bolts and nuts and gearwheels and rods and plates, was maybe even better, that would allow for heavy mechanical constructions too.

I guess the germans would have fisher technic associations, which I guess is fun too, but I found it for the rich. Just when I had some friends who were into that, the electronical and digital boxes came into the picture, which I found lame and expensive shortly after when I delved into digitronics myself. But great fun. I'm sure that gates, flip flops, counters, and even buses and arithmatic units are the better way to learn about computers and programming.

A good univerity study (and probably even a lousy one, and a normal enough bachelor degree study, too) would always start with including the boolean, mathematical, and digital building blocks, to know what TYPE of machine at least we are programming. And then assembly, to know WHAT we are aggregating from in higher programming languages. Which are reasonably natural extensions of macro assembly programming with memory manegement constructs and some standard library for string handling, functions with formal arguments, and mathematical operations.

I mean to teach children the foundations of the computers world is not unlike teaching them how and engine or a society works, maybe, the former is technical, which requires technical skills and intelligence, though most people can learn to drive a car (but why would they? Because it makes them happier?), and the way society works is what the human race seems to have at least some distinct opinions about since Alexander the Great institutionalized schools, copernicus postulated the earth isn't the centre of the knowable universe, columbus invented, oops sorry, discovered the us of a, the french revolution and its guillotine, the civil war and two world wars, and not to forget Jesus Christ and the reformation.

Which is quite something to 'learn' about before we can be allowed to 'program' lives in the western 'civilized' world.

Computers contain no explicit information whatsoever about important concepts such as freedom, respect, distribution of riches and production goods, honesty, God and the devil, etc.

Just like railtracks don't.

Come to think about it some more, how do you teach children to be creative, or to create an atmosphere where you can be that? And to be decent about the nice things in life. Value a good encyclopedia over some rulebooks to achieve world dominion. About the value of relaxation and a good enough life, hobbies, or the ways out of the slum through making international business machines in way which can be considered legitimate and acceptable business? The value of rational behaviour

TV: Because I can't get around the importance of the idea of this page, I thought I'd add some more to it, of course please feel free comment. Though it is not necessarily a tcl/tk related subject, I think at least it is a good idea to teach people about programming and letting non-programmers understand what programming is about and get quick result trying things for themselves, using tcl/tk.

For children of young age, one may want to play simple enough games of programming nature, such as:

set a "something"
set b "something else"
puts "$a & $b"
set b "something completely different"
puts "$a & $b"

I guess from 7 or 8 they could get the hang of assignments and combined printing, that is natural enough. Just like simple expressions, and then combining those things, boring for programmers who advanced from doing that ages ago, but at least instructional, and not delusive as to what object method does what or what else there is.

AMG: As a kid I had a lot of fun with "Lego My Logo" Saturday conferences, making Lego cars that solved mazes and other fun stuff. But I had already learned programming with GW-BASIC and Lotus 1-2-3 spreadsheet macros. Yes, as a toddler I found 1-2-3 fascinating (my dad reports I called it "my 1-2-3 game") since I could turn the numbers and formulas into music, cursor movement, pretty graphs, and funny-looking ASCII characters. (I remember marveling at matched parentheses, hehehe.) Having these fun but challenging tools was also a great motivator for learning how to read thick reference manuals written by engineers. :^)

I wonder if there's a general lesson to be learned here. Or maybe I'm just a freak. :^)

AM: I was inspired by Will Duquette's work in the same direction. Unfortunately he did not finish it. But I have started to work on a small command shell to support the young programmer. This will be accompanied by a "book" -- well, right now, an extensive tutorial. One product that I want to share right now: A basic editor

VI 2003-12-21: I am teaching my daughter programming using Tcl as the language. She's really interested in drawing. We start with a canvas and for now, interactively type in (only create and delete) commands. Does anyone have a simple application for this. All I need is : File (Save, Open, Close, New, Run)One Canvas. A small window at the bottom of the canvas, where she can edit the script and then save it. I thought of a status line printing out the tag of the item pointed to in the canvas, but I think I just want her to run the whole script after any modifications she makes.

2003-12-21 VI So my attempt at that gidrw

2005-02-21 MC: There is a discussion at [4] about what programming language to use to teach children. Perhaps a good time for some Tcl Advocacy?

(Moved from: Ask, and it shall be given # 4)

wdb 2006-05-17: Hi everybody! Is there any tutorial, or sample of ideas for such, intended for children (aged 10-18)? E.g. some popular game simply to realise in Tcl/Tk (except Lara Croft because tomb raidering is evil)? Any idea welcome!

[unperson]: 2006-05-17 Ah! Lara Croft raiders graves! Bad lady! :-) Didn't know that! I remember a few months back seing a project on [Project Forum] where a few wikiTzens were working collectively on a tutorial for children. I believe Larry Virden participated in it. Perhaps someone has the URL.

MG: I'm not sure exactly what's on it, but there's a page on the wiki to help you Teach programming to children.

[unperson]: Indeed! This page has a lot of info. Thanks again Mike!

Wolf-Dieter: If you want your kids to learn how to program, this is what I suggest:

Get them a stack of index cards and on each card, write one Tcl function. One simple one. Such as: how to create a window. Get the biggest size of index cards. In North-America the biggest size is: 8 X 5 inches. I don't know about Germany. Cards are very handy and fun to play with. I still have the ones I used to learn C!

Example: the children will copy the code and will create a window on the screen. Sounds boring? Well not quite, believe me! They'll be thrilled at simply making a window on the screen and playing around with the index cards. Remember when you started programming. The same happened to you. Everything was magic!

Go very slowly. One function a week. That is 52 a year! Or one every two weeks.
Then you move on to more complex stuff. Combining simple functions. Still using index cards.

For each card, write the objective: ex: Creating a window.

You'll see how fast kids learn when learning is done slowly, systematically and gradually. I know so, for I have been a teacher before and I still teach myself stuff. German for example.

You'll see that you don't have to come up with a game to interest them. Anything they will be able to do well will keep them entertained!

If you want to type in the contents of your tutorial here on a WikiT page, I could also learn since I am also a beginning beginner.

Lars H 2006-12-29: The issue of a programming environment for children has been discussed above. Yesterday TclTalk appeared on the Wiki, and it could be what was wished for; I haven't had the time to check it out, though.

tb 2008-08-01: Although TclTalk wants to be a beginners first Tcl/Tk environment, it is far from appropriate for children. Its straight appearence is more targeted towards programming students, teachers or enthusiasts. Children need a much closer turnaround from tweaking to running and a more appealing outlook.

LV: So often, tutorials I've seen focus on teaching individual commands, syntax, etc. To me, it would seem that an alternative approach would be to pick small projects and teach the ideas of moving from an idea like "hey, I'd really like to be able to ..." to conceptualizing the idea, how to iteratively build a program, tossing false starts, and deciding when good enough is enough.

JM 2008-01-07: (imho)

I think robomind could be a good starting point for kids.

AK 2008-01-08: Another thing to look at would the OLPC (One Laptop Per Child) [5] [6].

Alice [7]:

"Alice is an innovative 3D programming environment that makes it easy to create an animation for telling a story, playing an interactive game, or a video to share on the web. Alice is a teaching tool for introductory computing. It uses 3D graphics and a drag-and-drop interface to facilitate a more engaging, less frustrating first programming experience."

tb - Which reminds me of Squeak eToys - Smalltalk for children at [8]. eToys runs on PCs and on the OLPC.

JNC 2009-12-15: Manning Press has a book title "Hello World: Computer Programming for Kids and Other Beginners"

. The language they use throughout the book is Python. Maybe some ideas could be gained from the book. Despite it being python, I ordered it for my 10 year old.

Qogo - A New Logo

Category Education

See Also edit

Resources edit

Description edit

Details edit