Here is the very latest draft of a document summarizing the programming concepts in Scratch:
Word version:
http://scratch.mit.edu/files/program-concepts-v5.doc
PDF version:
http://scratch.mit.edu/files/program-concepts-v5.pdf
Please share your comments and suggestions!
Revised 07/19/2007
Offline
Could you put that up as a PDF file? I don't have MSword and you used some features that are not understood by Pages.
Offline
I really like this draft! (I'll translate it into Hungarian and add to the Hungarian Scratch homepage.)
Why don't you use a 'wait until...' instead of 'forever if' & 'stop script' at "time triggering"?
Offline
I'm glad you suggested that change to the "time triggering" script, Bernatp. I changed it to "repeat until" (since we didn't show that block elsewhere). What do you think?
(I posted the link to the revised document in my first post at the top of this page, so that newcomers download the latest version.)
Thank you for your suggestions!
Offline
Problems with code snippets:
Is "say nothing" a block? I thought the block was just "say" with a blank field.
The "forever if touching stereo" should have a "play sound and wait" , not just "play sound", I think.
Similarly, the "if touching goal" should have a wait until not touching goal after the change score by 1.
"change costume by 1" has been (sadly) eliminated from the language. You now need to use "next costume"
The forever loop "set size to mouse x %" should probably also have a wait 0.05 seconds after the set size.
Offline
Okay, I'm incorporating all your changes, Kevin (with just one exception -- the last one, "set size to mouse x %" I like having being dynamic without a wait. I'm interested to know why do you recommend the wait in that one?)
The "waituntil not touching goal" is a really nice solution! It assumes a parallel stack that moves the sprite, is that right? I like it a lot! I used a much simpler, "kludgier" solution on the "Keep Score" card: move -100 steps.
Offline
Hmm, I'm now I'm thinking for the purposes of this handout maybe to use the "move -100 steps" instead of the "waituntil not touching goal". For two reasons:
1) so that the variable stands out more than the conditional statements.
2) so that if someone tries to add the sprites' movements to that same stack it won't get stuck in the "waituntil".
Do you think
forever
if touching goal,
change score by 1
move -100 steps
is okay --or too rough a solution? (One downside is that for many games you don't want the moving object to jump backwards.)
Offline
I like to teach students not to have forever loops without some sort of wait that will cause time to pass. I regard busy-wait loops as a flaw in a multi-threaded program, and one that can cause serious behavior changes in different implementations (as many people have seen going from the squeak scheduler to the java scheduler).
I think that student should see the construct
forever if <cond>
action
wait until not <cond>
pretty soon---it has been one of the more frequent solutions to requests for help on the forum, and it is one of cleanest ways to get a "do-once-per-activation".
Perhaps a different context (maybe involving mouse down?) would be better for the first example of this.
Offline
I'd like to suggest changing the iteration looping block just for the simple reason that its outcome doesn't match to the code - the sprite doesn't get bigger forever - it eventually stops growing once the spite fills the screen :-)
how about
forever
...change size by 100
...wait 1 sec
...change size by -100
...wait 1 sec
or
forever
...move 50
...turn 20
...wait 1 sec
or whatever you want - as long as it can go on "forever" (or until the next system crash :-) )
regards
Simon
Offline
Thank you Natalie, this is exactly what I was looking for...even though I'm not sure I follow things like "iteration looping block," this will help me get there.
I'm curious about putting recursion in the "not introduced" list. If you broadcast a message at the end of a script that picks up the same message, isn't that recursion?
Karen
Offline
I have the same question as Karen. From comments in the forum, this apparently doesn't count since the broadcast and wait is only one deep and apparently some algorithms want to keep the entire call "tree" open.
While I can understand the distinction, I am a bit confused as to why one "is" and one "isn't" recursion rather than representing different levels of support for recursive calls. Not really asking for an answer here, it's a bit of an abstract question, but a reference or two would be nice.
Offline
A broadcast to restart a script is "tail recursion" (see the Wikipedia article on "tail recursion").
Tail recursion is a special case of recursion that can always be optimized out to a simple loop, while true recursion requires a stack of return locations to be able to continue where the routine was called from.
Offline
Thanks for the clarification and the reference.
One last question on the subject. Is there a "well known" problem that has a recursive solution but cannot be solved by an itterative approach (even if it is a very difficult implementation)? I suspect there must be one but I couldn't find it on a quick search - I probably wasn't searching with the correct terms.
Offline
Anything that can be done by recursion can be done by iteration plus a stack.
Some concepts are easier to express as a recursion, some are easier to express as iteration.
Offline
Thank you for the further suggestions (and helpful discussion of recursion)!
I have now posted version 4.
Word version: http://scratch.mit.edu/files/program-concepts-v4.doc
PDF version: http://scratch.mit.edu/files/program-concepts-v4.pdf
Changes:
* sequence: new example
* iteration: new example and wording
* conditional statements: new example
* variables: revised example
* real-time iteraction: new example
It would be great if you could look over the revisions and see if they make sense.
Offline
Kevin, I've added a wait to all the forevers, as you suggested, except the new example in "variables.' Others here really want that code to be simple to keep the emphasis on the variable blocks.
I think we should highlight your "wait until not touching" code in other places, including future sample projects--and a Scratch card?
Offline
Comments on revised "programming concepts and skills" (v4)
sequence: good, though play-sound starts a parallel action. You might want play-sound-and-wait.
iteration: good
conditional statements: traditionally, this means if-then and if-then-else (sometimes switch statements), but does *not* include loops, so the "forever-if" does not belong here---that is an iteration, not a conditional. Similarly, wait-until belongs under synchronization, not conditionals.
variables: ok
threads: ok
synchronization: I would say that "wait until" is synchronization, while broadcast and when I receive are triggering.
real-time interaction: ok
time triggering: I don't like the loop with no internal waits, as it relies on the rather uncertain fair scheduling of threads.
boolean logic: ok
random numbers: ok
even handling: this would be a good place to mention the when-I-receive block
object-oriented programming: OK, but a bit of a stretch since there aren't even multiple instances of objects.
user interface design. ok, though having the drum sound start after the light has dimmed again will feel awkward. The right way to do that interface needs two parallel threads:
when sprite1 clicked
broadcast hit drum
change brightness effect by 25
wait 0.2 sec
change brightness effect by -25
when I receive hit drum
play drum 48 for 0.25 secs
data types: scratch is *very* weak on data types, since costume names and numbers can both be used in "change costume", and numbers and strings can bothe be used in "say". About the only place strong typing is done is the boolean/number distinction, which is more annoying than useful, since there are no boolean variables. I'd say that scratch is mostly an untyped language, but very inconsistently so. I'd leave out data types, since this is more of an embarassment than a feature of scratch.
Also in the "left out of scratch" :
procedures and functions
comments
data types (including strings)
text input
Offline
Kevin, that was extremely helpful that you went through the whole document so thoroughly. I've posted version 5 which incorporates many of your changes:
http://scratch.mit.edu/files/program-concepts-v5.pdf
1) Sequence: Changed to "play sound and wait", as you suggested.
2) Conditionals: Made suggested changes (Changed to "if" and removed looping commands that checked for conditions).
3) Synchronization: Haven't changed yet --still under consideration
4) Time triggering - We ended up removing that one to focus on a smaller list.
5) Event handling - Haven't changed yet.
6) Object-oriented: Removed.
7) User interface: Changed code (simpler but hopefully gets the point across).
8) Data types: Removed.
9) Left out of Scratch:
Added procedures and functions, and text input. We hope to add comments soon so we didn't add that. Also didn't add data types since we already have data structures on the list, and since some here still contend that we are giving the very basic beginning steps preparing students for learning data types later (by using different shapes for numbers and booleans).
Thank you again!
We're hoping to make a nicely formatted version soon, so still open for comments and suggestions.
Offline
Hi, the pdf is useful, especially the summary of what scratch does not teach. I put it on the list I am compiling.
http://www.kidslike.info/scratch_computer_programming_tutorials
http://www.kidslike.info/what_scratch_teaches_and_does_not_teach_in_terms_of_programming/getpage.apx/pageid=031045103807
Are there any updated versions? Thank you.
Offline