[racket] Doing collision detection in universe.ss

On Nov 28, 2012, at 7:37 AM, Yaron Minsky wrote:

> I do think that a good design goal for Racket's kid-oriented libraries
> would be to be feature compatible with Scratch.  It would be great if
> there were good ways of doing everything that Scratch can do, from
> playing sounds to detecting collisions, to (more aggressively) on-line
> hosting of the final result.  I'd love it if Racket were strictly
> better than Scratch for someone who really can figure out how to
> program, but it's just not true now.

I was playing with this, too, a year and a half ago (after watching one of Dan Garcia's typically-inspiring talks).  To my mind, the big thing missing from Scratch-based curricula was testing, because their uncompromisingly-imperative paradigm doesn't allow for any way to test a program other than "run it, watch it, and decide whether it looks right."  In order to fit real testing into a beginning curriculum, I wanted to make Scratch more functional.  Which gets difficult because anything you do with a sprite affects not only the sprite but the global graphics window.  And then life happened, and I didn't get back to the project. :-)

Keep in mind, however, that there are some tasks for which universe, image, et al are much better than Scratch, notably raster graphics.  The picturing-programs library includes "build-image" and "map-image", analogous to "build-list" and "map", which produce raster images by computing the color of each pixel independently and which can be used by students who haven't seen loops or recursion yet.  (These were inspired by a similar impulse to Yaron's above: I wanted to beat the Python-first curricula at their own game, and many Python-first curricula introduce nested for-loops early in order to process images pixel by pixel.)


Stephen Bloch
sbloch at adelphi.edu

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20121128/45e5cd3c/attachment.html>