[Arjen Markus] (5 june 2003) 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 [http://tcl.projectforum.com/young/] where writing began. More contributions would be in order. ---- Here is a published article using Tcl to teach graphic programming to young children at O'Reilly's Mac Dev Center.com http://www.macdevcenter.com/pub/a/mac/2003/12/16/begin_programming.html (12/22/2003, Roy Terry) ---- 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] (6 Jun 2003): 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 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. ----- I Thought that this was called [Logo] -- [JBR] [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] Byt 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] (13-06-2003): "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: [http://developers.slashdot.org/article.pl?sid=03/06/11/1348236&mode=thread&tid=126&tid=146&tid=156&tid=99] . 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] (13 Jun 2003): 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] (19 june 2003) 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] (19 june 2003) 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] ''(19 jun 03)'' After seeing the page show up on the '''recent changes'''[http://wiki.tcl.tk/4] 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] (20 june 2003) 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] ---- [RS] contributes: [A minimal editor explained] - [A minimal doodler explained] ---- 2003-12-21 [VI] 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 [http://pluralsight.com/blogs/dbox/archive/2005/02/20/6009.aspx] 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]) 2006-06-6 [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], 29 Dec 2006: 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] 1 August 2008: Allthough 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] 7-Ene-2008: a few good examples (imho) * http://www.robomind.net/ * http://scratch.mit.edu/ I think robomind could be a good starting point for kids. ---- [AK] Jamboree-8 2008. Another thing to look at would the OLPC (One Laptop Per Child) [http://laptop.org/laptop/] [http://olpc.com/]. ---- Alice [alice.org]: ====== 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. ====== ---- !!!!!! %|[Category Education]|% !!!!!!