Scratch

I have looked at both and I have to say that Scratch is much faster to learn and yet they can do a lot. From Scratch you can move them to KPL or Phrogram, which will be much easier and from there it is easy to go to JavaScript, ActionScript, or even C/C++.
The reason is that SmallTalk, which cool, is not much like most modern languages. Scratch is pretty close in form to what you would do in a normal language as a basic step.

I have been teaching elementary school kids (2nd grade to 5th) and they can make quite powerful games (always a good way to learn). From what they learn, they can move to 2D and 3D games in Phrogram quite readily.

I will note a few annoyances in Scratch though: x/y coordinates are not like computer systems, but like school geometry. I think that was a major mistake. Oddly, direction is not like school geometry or computers, but uses a 0 to 180,-179 to -1 model which is very odd and screws up normal computations. Of course, there is no sin/cosin nor even square root, so may not matter. I moved the kids from Scratches direction model to xdelta/ydelta vector models for them, since it is easier to understand bouncing and gravity and the like, and works well in any language (and they do not have to know about sin/cosin and square root).

The main trick is to steer them to use proper techniques and avoid oddities like "forever if" which is not like "while" in any language. I have had them using messaging as a kind of subroutine model, but watch out because "wait" does not work on the same sprite.

A subroutine (aka function or method) is a way to break up your application. Of course Scratch uses Sprites as objects with their own thread (each sprite and the "stage" run their own script by themselves, unlike a normal program which is sequential unless you use threading). You can have multiple scripts per sprite, but this teaches methods which will be confusing and not useful in other languages (unless you are a hardware programmer). However, you can use messages both to communicate between sprites (and create synchronization points) as well as between scripts for one sprite. So, you may have a script fragment in a sprite which makes some calculations or performs some checks. Instead of replicating that over and over, you can run it by sending a message to it to perform the task. This is we use service and accessor functions in any other language. I had the kids create a log sprite (which is hidden) which contains a number of update and check functions (little scripts started by "When I receive" and which end when done - no forever). Then you can use "Broadcast and wait" to run them. This is much more in line with how they will use any other language.

I hope this clarifies the point. Regards, Paul

Hi David. I spent about 2 hours and wrote 4 games, each demonstrating different aspects. When I teach programming to younger kids, I emphasize the 4 basics: directions, iteration/looping, conditionals, and variables. I personally use a whiteboard at 1st (draw a checkerboard with obstacles and move a picture of mario on it) to walk them through the difference between how you tell a person (go to end), how you operate as a player (move  based on what you see), how you could program that exact path (logo style), and then how you could program using conditions (when at wall, turn left). I then start them with move/direction animation and use repeat count vs. forever to get the basics of looping under control. Adding a conditional (such as if on edge, bounce) reinforces conditionals and the difference between pre-worked out instructions and adapting to the environment. With younger kids, I always allow a lot of time for them to customize things (both the pictures and the programming) by encouraging them to try to add interesting changes and the like. I want them to feel ownership.
I then move them to a target catching game, which is very simple in Sprite. So, one ball (or other sprite) that you control (arrows) is being chased by another (which is just heading towards you on each step). This brings in variables in the simplest way (a hit counter) and real conditions (both touching, and counter exceeds limit so game ends). Adding something to chase (while being chased) adds randomness but also NOT and AND/OR type booleans (a new way of thinking for many kids).
I then created a target shooting game because it uses a lot more variables and also communication, but also fun for them (creative aspects). More importantly, you can use it to teach object oriented concepts (abstraction). So, different targets have very different behaviors (when moving back and forth and when hit), but all use a common model for movement and hit detection and the like (messages, local variables, common code fragments). Scratch does not actually make this as easy as I would like, but so be it. I note that I use a step-wise refinement approach with them: start with a basic game, enhance, review results, think how you want to enhance, do it again (and sometimes rip up and throw out sections to do a new way as needed by the refinement). This somewhat bottom up approach (like deconstruction of a game) is important in learning the concepts of algorithms, in my view. For example, in the target game, we added a demo mode (game plays by itself to show how it works). This forced them to decouple player actions from underlying actions (most kids have some trouble with this at 1st) and to split up the script into functions (or functional units if you prefer). That is a critical step, especially if you are moving them to a text language next (as I am).
The other games I had them work on were a race car game (more variables, more communication, moving from just reactive scripts to far more longer term, such as end handling, details, etc). The move from purely reactive scripts (all in the moment) to ones that handle init, termination, rare events, end triggered events (may or may not happen), timeout (wait so many seconds and then do something), and the like is an important one. It is the hardest step for many kids.
I wrote a few others, and also a number of algorithms (bouncing ball, game gravity impacting bounces/objects, acceleration/deceleration from contact (but only if the other thing is moving), etc). I used these to help them understand the idea of a bag of tricks and standard code - something common to all programmers.
Finally, I led them through a number of top-down design to implementation processes. The hardest challenge in this is getting them to set their ambitions in line with what they can reasonably do. But, I let them design what they wanted. Then, we divided up the design into components (blocks). We then looked at what was required/critical and set about defining and implementing them 1st (I let them do so, but with some guidance). I reminded them of the ripup-and-rewrite that was needed when they refined before, so they could plan better for how they would accommodate features they would add later - teaching them something many professional programmers have trouble with :-(
So, I did not use any of the programs out there, although I am sure there are plenty of good ones. I would suggest you look carefully at any in terms of how well they attack the problem. I would avoid any that use/abuse threading, because they will not have that available to them in any other language. That is, many create a number of simultaneously running scripts within one sprite. This may be easier for some people, but it is not how they will deal with any other language, and it can create debugging nightmares (due to race conditions, mutual exclusion issues with variables, unintended consequences, including working for the wrong reasons, etc). It also tends to lead to poor design practice (not ordering things logically to how you want them to flow, losing input/event to outcome modeling, etc).
So, hopefully this helps. I find that this then makes it easy to move on to a text language. I move the older ones on to Phrogram for 2 reasons: 3D graphics really gets them excited and is easy in that language, the text language is close enough to Scratch in most regards (no semi-colon, line oriented, no parenthesis, etc).
Regards, Paul

Last edited by pkimelma (2007-04-12 11:45:43)

The Phrogram Express version (free) works perfectly. They did not cut out anything in that sense. What you lose is the class viewer after 30 days (which is useful) and the ability to package up your own executables (which may be useful, depending on your model). I have been using the freeware version only because I cannot force my students to buy a copy). When I teach this class next time, I may have them pay a lab fee, so I can get them all a license (academic). This would ensure they get the latest version.

They have big plans, so down the road the distinction may be bigger.

The main thing to be aware of is that for the 3D graphics, you need to have a Windows PC and it has to have the latest version of DirectX. It also should be somewhat modern (>1GHz, 512MB or more memory is preferable). This is quite different than the lowered requirements of Squeak (for using Scratch).

If you will be using 3D graphics, they provide a lot of prebuilt space related meshes (e.g. spaceships) and skyboxes (e.g. stars, spaceship hangers, nebula, etc). But, you can also make your own. However, the 3D tools are harder to learn. Also, only a few can make the right .x files (DirectX) that will work. I have been using Wings3D and DeleD successfully and both are free. If you are an artist, you may enjoy that part, but leave plenty of time.

One thing I like about Scratch is that the blocks all match a conventional language scheme. That is, you can read the text on the blocks, and the constructs look enough like C/Java or other common languages to allow the kids to learn a model for syntax that they can use going forward. It is not much of a change to move to Phrogram for example.
The problem with some of these more meta languages is that they are endpoints: kids are often learning techniques that do not map well to other languages.

Hi Kevin. I also found Alice to be too confusing for kids and too restricted. I agree that its Java-lite approach has advantages, but it seemed to random in what they chose to use. I am not a big fan of logo, as you cannot make good progressions from the simplest to real programs. That is, it teaches a style that does not advance well in my opinion. For all but the youngest, I think a real control/loop/condition/variable language is ideal, as it teaches (or allows us to teach) all the fundamentals, including divide and conquer approaches to problem spaces (aka. top down programming). For kids, it is often crucial that you can get them to set their ambitions to match what they can actually accomplish. One way to do this is to let them choose a lofty goal, but define a subset to strive for 1st. Then, step-wise improvements to get to their goal.
Further, I like the drag-and-drop approach of Scratch as it encourages experimentation rather than discourages (since most kids type slowly).
As to your 11 year old, I agree that learning a lot of related languages can help with concepts (and they can figure out how to decompose meta-ops in one language into the primitives of another). But, the risk is that they learn a lot of bad habits and sloppy techniques. Learning the power of one or two languages allows one to better understand all the tools at their disposal. I find kids that learn many languages usually do not learn how to exploit the larger power of any particular one. This is especially true when it comes to concepts like classes, function/method abstraction and reuse, arrays, etc. I see a lot of programs that are very brute-force, and that is a shame.

I would argue that Scratch has a basic data structure model. Each Sprite can have local data (think members of a structure/class). Coupled with messages, you have a Smalltalk like abstraction and object model. Sprites can be manually instantiated (by copy, not by reference I am afraid), and they follow the paradigm OK (broadcast is broadcast and not narrow cast, so your instantiations would have to be list-like). But, I am finding that this actually helps the move to object encapsulation and iteration concepts. It does not help with polymorphism or the next level of abstraction (derivations), but the goal of a starter language is to get the basics under the belt. I have shown the derivation model a bit by having them clone a Sprite that is working properly and then change the costumes (only) of some of the clones. Now, you have a set of Sprites that behave a consistent way (isa xxx) and yet are derived (in looks). This seeds the idea of building blocks of abstraction, although it does not make the leap for them.

I do not agree that copying is not the essence. The idea of classes/objects is that you have a template and make instances. So, creating one sprite with its methods (scripts) and members (local variables) and then copying, can help get across the ideas of instantiating multiple instances from one template (class). The receive blocks are the interfaces (methods), so this all works in some broad sense.
I agree that one needs to move to lists and arrays as a way of accessing such items. Broadcast is more like a list automation model (automatically invokes the same method for each list member). One of the problems with Scratch is that the sprites cannot get their id and you cannot narrowcast (to a selected sprite), so it is not ideal. But, it can be an easy way to show the concepts.
Logo's instantiations of turtles is not really any better, and I think it is worse, since each one is identical (a clone). Sprite copying allows for easy abstraction by using costumes and optionally a "self" notion. I used a simple example for the kids of a local variable that they set for each sprite as a group member number. This allows the broadcast to be set/ignored based on the settings of a global. Again, not elegant, but shows some concepts well enough. Even hard derivation is possible using parent-child messaging.
But, that said, I am only suggesting that this can be used for teaching these important concepts in a simple environment, and not a technique to use in Scratch long term. I am assuming the kids will move on to a stronger language such as Phrogram.

Yes, I use the local variable "ID" in my example for the kids. I asked them some questions today about it (I teach on Mondays), and they all got the concept reasonably well. I agree that it would be far better if a by-reference approach existed (such as being able to say to use the scripts of sprite xyz). I also have suggested user functions for sprites which I do not think would be a problem for kids to understand, even the very young ones. See my posting (http://scratch.mit.edu/forums/viewtopic.php?id=98). That does not address the template/interface concept of abstractions, but is a clean step in that direction.
But, it does seem that even copying sprites is enough to get the idea of a number of sprites sharing the same exact code (script), but having their own data. The downside is that because they are copies, a change in code to one is not propagated to all. So, they have to use care.
I like your send-to block model as well. I think that is more natural than broadcast, both in terms of programming and in terms of how kids think (they have few cases where they broadcast anything, but many where they narrowcast). The analogue of send-to is "talking to a friend" vs. "talking to your class" (all).

One word of caution regarding Alice.  While I am quite a fan ofthe program, the current version (2.0) has one basic problem - several of the commands and features - including numeric arrays simply don't work correctly.  Add the fact that it has a "memory leak" problem and is thus very prone to crashing, and I think it would be a terribly frustrating environment for a beginning programmer.

The Alice development team is aware of the problems and the next version, available in a year or so (??),  is supposed to have the problems fixed and also be much more true to it's Java roots.  Hopefully this will really happen.

I've made a comparison of scratch with squeak here.

http://www.kidslike.info/teaching_children_how_to_program_computers_comparing_squeak_and_scratch

To play squeak games, you have to download a squeak plug-in. This is different from scratch. You can play scratch games at http://scratch.mit.edu if you have java enabled. You do not have to download scratch if you just want to play the games.

If you go to http://www.squeakland.org/,
click on the picture that says games, and then click on the tab "Games" you will find 4 squeak games to play.
Oddly enough, this page has the same url as the home page, so I cannot take you there directly.

This is very different from scratch. which has more than 150,000 games.

I haven't played with squeak, but I would guess that scratch can do everything squeak can. You can click on the Tutorials button from the main page to get to the tutorials.

One advantage squeak has over scratch is that it has versions for Mac and Unix, in addition to Windows.

Although firefox is a supported browswer, we could not get it to work in firefox. We had to use Internet Explorer.

Currently squeak and etoy mean the same thing. The website for both is squeakland.org.

Squeak began at Apple.

Here is my list of top scratch teaching resources.
http://www.kidslike.info/scratch_computer_programming_tutorials

Last edited by teachcomputers (2008-08-04 17:08:31)

You should show Scratch to your teacher - maybe they don't know about it!  Your classmates would be so happy if you introduced them to this